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(A)  Purpose 


The  purpose  of  this  document  is  to; 


provide  a  general  description  of  the  MOSIS^system;  ~  * 

•  / 

list  detailed  instructions  with  examples  of  how  to  use  MOSIS. 


The  MOSIS  system  provides  online  instructions  to  users.  This  document,  however,  is  addressed  to 
prospective  new  users  and  contains  information  on: 

•  what  the  service  offers; 


•  how  the  service  works; 

( . «  how  to  interact  with  MOSIS; 

•  how  to  become  an  authorized  MOSIS  user;  *~ 

f  •  how  circuit  designs  are  submitted,  processed,  and  tracked. 

This  document  includes  step-by-step  illustrations  of  information  retrieval  from  MOSIS  and 
step-by-step  illustrations  of  design  submittals  to  MOSIS. 

The  MOSIS  user  manual  (as  of  1  March  1984)  is  also  included  in  this  document;  however,  users 
should  be  aware  that  only  the  online  version  of  this  manual  is  up-to-date  to  the  time  of  its  retrieval, 
unlike  offline  documents  (e  g.,  this  manual)  which  are  current  only  to  the  time  of  their  printing. 
Instructions  for  obtaining  online  documentation  via  electronic  mail  are  included  in  this  document. 


(B)  What  is  MOSIS? 


Under  the  sponsorship  of  the  US  Defense  Advanced  Research  Projects  Agency,  the  Information 
Sciences  Institute  (IS!)  of  the  University  of  Southern  California  has  been  operating  the  MOS 
Implementation  Service  (MOSIS)  for  over  three  years.  During  this  time,  MOSIS  has  met  its  design 
objectives.  It  has: 

*  reduced  the  high  cost  of  VLSI  prototyping; 

*  shortened  turnaround  time  for  VLSI  prototyping; 

*  freed  designers  from  fabrication  idiosyncracies; 

*  made  design  less  dependent  on  specific  fabrication  lines. 

MOSIS  serves  as  the  interface  between  designers  of  integrated  circuits  and  the  vendor  base  that 
fabricates  the  devices.  By  centralizing  and  automating  the  idiosyncratic  requirements  of  fabrication 
vendors,  MOSIS  saves  designers  the  enormous  amount  of  time  and  energy  they  would  otherwise 
expend  in  becoming  familiar  with  vendor  peculiarities. 

MOSIS  achieves  cost  reduction  of  one  to  two  orders  of  magnitude  by  spreading  the  cost  of  fabrication 
over  many  projects  submitted  by  designers  from  several  universities  and  other  research  and 
development  organizations. 

The  greatest  impact  of  MOSIS  is  in  the  community  it  has  created.  The  MOSIS  community  not  only 
shares  the  fabrication  services,  but  experience,  cells,  tools,  software,  and  more.  MOSIS  now 
supports  nMOS,  CMOS/Bulk,  CMOS/SOS,  and  Printed  Circuit  Board  technologies.  The  rapid  growth 
of  both  the  MOSIS  service  and  its  user  community  proves  that  MOSIS  is  a  very  useful  and  important 
service  to  both  the  academic  and  the  R&D  communities. 
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(C)  How  Does  MOSIS  Work? 

C.1 .  MOSIS  and  the  User 

MOSIS  involves  various  aspects  of  multiproject  wafer  assembly,  quality  control,  and  interaction  with 
industry,  as  shown  in  Figure  1 . 

The  design  of  working  chips  requires  more  than  just  compiling  artwork  which  adheres  to  the 
published  geometric  and  electric  design  rules.  It  requires  the  application  of  various 
computation-intensive  tools,  such  as  SPICE  and  timing  verification. 

Designers  use  any  available  design  tools  to  create  artwork  files  that  are  sent  to  MOSIS  via  the 
ARPANET  or  other  computer  networks.  MOSIS  compiles  a  multiproject  wafer  and  contracts  with  the 
semiconductor  industry  for  mask  making,  wafer  fabrication,  and  packaging.  MOSIS  then  delivers 
packaged  1C  devices  to  the  user.  The  user  perceives  MOSIS  as  a  black  box  that  accepts  artwork  files 
electronically  and  responds  with  packaged  1C  devices,  as  shown  in  Figure  2. 

Though  MOSIS  may  be  instrumental  in  providing  cells  and  design  tools  to  the  user,  it  is  the  sole 
responsibility  of  the  user  to  see  that  the  submitted  patterns  yield  working  designs.  One  may  compare 
MOSIS  to  a  publisher  of  conference  proceedings  compiled  from  papers  submitted  in  "camera-ready" 
form,  where  the  publisher’s  responsibility  is  to  produce  the  exact  image  on  the  right  kind  of  paper 
using  the  appropriate  ink  and  binding  —  but  not  to  address  the  spelling,  grammar,  syntax,  ideas,  or 
concepts  of  the  various  papers. 

MOSIS  provides  a  clean  separation  of  responsibility  for  the  "printing”  of  chips.  The  semiconductor 
manufacturer  is  responsible  for  the  processing  of  the  parts  and  must  satisfy  MOSIS’s  rigorous  quality 
control.  MOSIS  is  responsible  to  the  user  for  the  quality  and  timeliness  of  the  fabrication.  The  user  is 
responsible  for  the  proper  design  of  the  parts  and  may  use  any  design  methods  he  finds  appropriate 
for  his  needs. 

It  is  quite  common  that  very  advanced  and  sophisticated  chips  fabricated  by  MOSIS  work  on 
"first-silicon".  An  example  of  this  is  Caltech's  MOSAIC—  this  is  an  amazing  accomplishment  of  the 
existing  design  tools.  Unfortunately,  this  is  done  at  a  considerable  cost;  for  example,  it  is  estimated 
that  Caltech's  MOSAIC  chip  consumed  over  1,000  CPU  hours  on  various  VAXes  before  it  was 
submitted  to  MOSIS  for  fabrication. 
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Figu  re  1 .  General  How  of  the  MOSIS  system 


C. 2.  Step  by  Step  Processing 

MOSIS  usually  aggregates  several  small  projects  submitted  by  the  same  organization  into 
Multi-Project-Chips  (MPCs),  as  shown  in  Figure  3,  and  the  various  chips  of  the  same  technology  into 
Multi-Chip-Wafers  (MCWs).  It  is  common  for  MOSIS  to  have  wafers  with  over  100  individual  projects, 
as  in  the  Orly  run  shown  in  Figure  4,  and  wafers  with  about  50  different  die  types  of  several  different 
sizes  as  in  the  Nicole  run  shown  in  Figure  5. 

MOSIS  maintains  strict  quality  control  at  each  point  of  fabrication.  After  processing  and  grouping 
project  data,  MOSIS  writes  magnetic  tapes  for  the  tooling  process.  Typically,  the  tooling  is  a  set  of 
E-beam  IX  masks.  The  tooling  is  delivered  to  the  appropriate  fabrication  line,  where  it  is  checked  to 
be  within  the  QA-specification. 

After  fabrication,  wafers  are  DC  parametrically  probed  by  the  vendors  using  their  Process  Control 
Monitoring  (PCM)  devices.  MOSIS  then  performs  DC  parametrical  probing  using  its  own  set  of  test 
structures  to  extract  SPICE  parameters  and  to  assure  that  the  wafers  indeed  meet  the  MOSIS 
specifications.  In  addition  to  parametric  measurement  structures,  MOSIS  wafers  contain  test  devices 
which  evaluate  the  relative  yield  rate  of  individual  conducting  layers.  Dies  with  random  fault 
structures  are  probed  during  DC  parametric  testing  to  detect  excessive  frequency  of  faults  in  each  of 
the  conducting  layers.  Electrical  tests  are  performed  to  reveal  mask  alignment  errors  and  layer  to 
layer  oxide  thickness. 

After  the  DC  probe  testing  is  complete,  the  wafers  are  probed  again  to  measure  the  relative  yield  of 
some  large  digital  functions  (canaries).  These  functions  are  usually  static  and  dynamic  memory  and 
enable  assessment  of  the  lot  yield  relative  to  other  lots  from  the  same  fabricator  and  from  other 
fabricators. 

Finally,  one  of  the  wafers  (usually  not  passivated  during  fabrication)  is  examined  with  a  scanning 
electron  microscope  to  monitor  the  quality  of  metal  step  coverage  and  contact  pits.  If  there  is  any 
indication  of  spiking  in  the  contact  pits,  the  wafer  will  be  metal -stripped  and  examined  further. 

After  testing  is  complete,  MOSIS  selects  the  wafers  which  best  match  the  specifications.  These 
wafers  are  diced  into  individual  dies  which  are  typically  packaged  in  28-,  40-,  and  64-pin  DIPs  and 
84-pin  grid  arrays.  The  bonding  of  chips  into  packages  is  performed  according  to  either  the  standard 
pad  frame  bonding  that  the  user  specified  or,  for  custom  pad  frames,  custom  bonding  maps  are 
produced  by  MOSIS,  as  shown  in  Figure  1-4. 
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Figure  5:  Multi-Chip-Wafer  from  the  NICOLE  run,  containing  Multi-Project-Chips 

of  different  types  and  sizes. 


(D)  Initiation  to  the  MOSIS  System 
D.1 .  Access  to  MOSIS 

MOSIS  users  must  have  access  to  either  the  ARPANET  message  system  (directly  or  through  some 
other  network  such  as  MILNET  and  CSNET)  or  to  TELEMAIL. 

MOSIS’s  electronic  mail  addresses  are  MOSIS@USC-ISIF.ARPA  (in  the  ARPA  Internet)  and 
MOSIS/USCISI  (in  the  TELEMAIL  system).  Users  may  communicate  with  MOSIS  via  either  of  these 
mail  systems. 

D.2.  Meeting  MOSIS 

Users  may  request  information  from  MOSIS  on  various  topics,  even  before  becoming  authorized 
MOSIS  users.  A  prospective  user  need  only  know  the  MOSIS  address  to  receive  instructions  on 
retrieving  MOSIS  information.  The  user  simply  sends  a  message  to  MOSIS  saying  anything  at  all,  as 
shown  in  Figure  6,  and  MOSIS  responds  with  an  introductory  message,  as  shown  in  Figure  7.  This 
response  contains  examples  of  the  basic  formats  for  various  MOSIS  information  requests. 

After  receiving  the  MOSIS  introduction,  the  user  may  request  the  list  of  topics  in  the  MOSIS 
vocabulary,  as  shown  in  Figure  8.  MOSIS  will  respond  to  this  request  with  a  list  of  topics  on  which 
information  is  available.  Appendix  II  is  the  current  list  of  information  topics.  A  user  may  then  request 
information  on  the  topic  "USER-MANUAL"  as  shown  in  Figure  9.  MOSIS  will  provide  the  user  manual 
by  "return  mail",  like  the  one  included  in  this  document,  except  that  it  will  be  updated  to  the  time  of 
retrieval.  This  is  a  very  long  document,  which  may  exceed  the  capacity  of  some  mail  systems.  If  this 
is  the  case,  users  should  include  in  their  information  request  the  parameters  listed  in  Section  C.2.1  of 
the  user  manual  (Appendix  III). 

A  user  may  also  request  information  on  several  topics  at  a  time,  as  shown  in  Figure  10. 

D.2.1.  Completing  a  MOSIS  Request 

The  most  efficient  way  to  signify  am  end  to  a  MOSIS  request  message  is  by  including  as  the  last  line 
"REQUEST:  END".  MOSIS  will  interpret  this  string  as  the  completion  of  all  requests  in  the  message 
and  will  therefore  begin  processing  the  message  immediately. 

This  request  must  be  the  last  line  of  the  entire  request  message.  It  is  good  form  to  include  it  in  all 
request  messages.  H  is  mandatory  to  include  it  in  all  messages  containing  CIF-FRAGMENTs  (see 
Section  F.2)  to  ensure  proper  receipt  of  the  CIF. 


To:  MOSIS8USC-ISIF . ARPA 
From:  OllveSNavy 
Subject:  First  message 

Hello  out  there!!! 

Can  anybody  hoar  me??? 


Figure  6:  A  first  message  to  MOSIS 


To:  OllveSNavy 

From:  MOSIS8USC- ISI F . ARPA 

Subject:  No  Request  found 

Dear  user: 

This  is  ISI's  MOS  Implementation  System  (MOSIS). 

We  have  received  a  message  from  you  containing  no  recognizable 
request  for  service.  If  you  eish  to  use  the  services  of  MOSIS. 
kindly  send  to  M0SIS8ISIF,  or  via  TeleMall  to  MOSIS/USCISI .  a 
Net  message  containing  the  following  lines: 

REQUEST:  INFORMATION 
TOPIC:  GENERAL 

MOSIS  will  send  back  a  Net  message  containing  information  on  how  to 
obtain  authorization  to  use  MOSIS. 

If  you  need  a  MOSIS  user  manual,  kindly  send  to  MOSIS  a  message 
containing  the  following  lines: 

REQUEST:  INFORMATION 
TOPIC:  USER-MANUAL 

MOSIS  will  also  supply  Information  on  other  topics  relating  to 
the  MOSIS  service.  To  obtain  the  list  of  topics,  kindly  send 
to  MOSIS  a  message  containing  the  following  lines: 

REQUEST:  INFORMATION 
TOPIC:  TOPICS 

To  bring  some  matter  to  the  attention  of  the  MOSIS  team,  kindly 
send  to  MOSIS  a  message  containing  the  following  lines: 

REQUEST:  ATTENTION 

followed  by  the  teat  you  wish  to  bring  to  their  attention. 

Cheers, 

MOSIS 


Figu re  7:  MOSIS  response  to  first  message 


13 


(E)  How  to  become  an  authorized  MOSIS  user 

Authorization  to  use  the  MOSIS  service  is  granted  by  either  ARPA  or  NSF.  Prospective  users  must 
justify  their  intended  use  of  the  service  to  their  sponsoring  agency. 

E.1 .  DoD-sponsored  Users 

DoD-sponsor-od  users  should  contact: 

Paul  Loslsban 

OARPA/IPTO 

1400  Wilson  Blvd. 

Arlington.  VA  22209 

Net  address:  LoslebenBUSC-ISIA. ARPA 

E.2.  NSF-sponsored  users 

NSF-sponsored  users  NOT  sponsored  by  DoD  should  contact: 

Bernard  Chern 

NSF  --  National  Science  Foundation 
1800  G  Street,  NW 
Washington.  DC  20550 

Net  address:  ChernBUSC-ISIA. ARPA 

In  the  process  of  seeking  NSF  approval,  the  user  must  have  their  NSF  Principal  Investigator  complete 
NSF  Form  1171  ("Authorization  Request  for  Use  of  DARPA  VLSI  Fabrication  Facility"),  and  return  it 
for  approval  to  the  appropriate  NSF  program  officer  who  monitors  the  grant. 

E. 3.  Notification  of  Authorization 

Applicants  will  be  notified  when  they  become  authorized  MOSIS  users,  and  a  MOSIS  account  will  be 
established.  The  authorization  process  is  handled  entirely  by  DARPA,  NSF,  and  MOSIS. 

(F)  After  Authorization  —  Submitting  Circuit  Designs 

F. 1 .  MOSIS  User  Manual 

The  MOSIS  user  manual  includes  all  requests  and  parameters  required  to  submit  a  circuit  design.  All 
new  users  should  request  the  online  version  of  the  user  manual.  Only  the  online  version  is 
guaranteed  to  be  current. 

Appendix  III  is  the  MOSIS  user  manual  as  of  1  March  1984. 


F.2.  Design  Library 

MOSIS  maintains  a  library  of  commonly  used  circuits  for  the  MOSIS  community  Currently,  the  library 
contains  input-output  pad  circuits  plus  several  PLA  fragments  and  signal  buffers  that  can  be  used 
within  a  PLA  generator  program  within  the  user’s  CAD  environment.  It  is  highly  recommended  that 
users  incorporate  pad  library  cells  in  their  designs  because  the  pads  are  configured  to  provide 
assurance  that  there  is  sufficient  pad-to-pad  spacing  and  pad  area  for  reliable  wire  bonding.  Also, 
the  pads  are  designed  to  provide  a  measure  of  electrostatic  discharge  protection  for  on-chip 
circuitry.  Details  for  accessing  the  library  are  in  Section  C.2  of  the  user  manual  (Appendix  III). 

Contributions  of  circuitry  to  the  library  which  may  be  of  general  interest  to  the  community  are 
encouraged. 

F.3.  Steps  for  Submittal 
F.3.1 .  Intent  to  submit 

Once  authorized  to  use  the  MOSIS  service,  the  user  may  submit  designs  for  fabrication.  The  artwork 
for  these  designs  must  be  in  Caltech  Intermediate  Format  (CIF).  Before  submitting  the  CIF,  the  user 
must  send  a  message  to  MOSIS,  informing  MOSIS  of  his  intent  to  submit  a  new  project,  as  shown  in 
Figure  11.  MOSIS  will  acknowledge  this  intent  to  submit,  as  shown  in  Figure  12.  The  response  from 
MOSIS  will  contain  a  project  ID;  all  future  messages  to  MOSIS  regarding  this  project  should  reference 
both  this  ID  and  the  project  password  (P-PASSWORD)  as  assigned  by  the  user. 

F.3.2.  CIF  verification 

When  the  artwork  is  ready,  the  user  submits  it  to  MOSIS  for  preliminary  checking,  as  shown  in 
Figure  13.  The  syntax  of  the  CIF  is  checked  to  verify  that  it  was  received  correctly;  in  addition,  MOSIS 
computes  the  project  size  and  pad  count  (for  a  custom  project  frame)  or  pad  layout  (for  a  standard 
frame)  and  checks  them  against  the  values  declared  by  the  user.  MOSIS  does  not  check  if  each 
project  complies  with  design  rules  —  that  is  the  responsibility  of  the  designer.  MOSIS  informs  the 
user  that  the  CIF  file  is  queued  for  validation,  as  shown  in  Figure  14. 

After  the  CIF  check,  MOSIS  will  respond  with  either  a  pass-message,  as  shown  in  Figure  15,  or  a 
fail-message,  as  shown  in  Figure  16. 
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To:  M0SIS8USC-ISIF . ARPA 
From:  01 IveSNavy 

Subject:  Intent  to  submit  new  project 


REQUEST:  NEW-PROJECT 


0-NAME : 

AFFILIATION: 

ACCOUNT: 

0- PASSWORD: 

NET-ADDRESS: 

MAILING-ADDRESS: 


P-NAME: 

P- PASSWORD: 
DESCRIPTION: 


TECHNOLOGY: 
LAMBDA : 
MIN-LAM80A: 
MAX -LAMBDA: 
PADS: 

REQUEST:  ENO 


01  Ive 

Navy 

78Q-675 

Popeye 

01 IveSNavy 

Ms.  0.  Oyl 

OP-9876 

NAS  Poseidon 

Massachusetts  02177 

VFFT 

Kaziboo 

This  is  a  device  to  compute  a  Very  Fast 
Fourier  Transform  of  sonar  data  which  Is  the 
key  to  the  security  of  underwater  rafts. 

It  works  according  to  the  principals  described 

In  [OYLBO]  and  In  . 

NM0S/MC1 

2.0 

1.5 

2.5 
24 


Figu  re  1 1 :  A  message  of  intent  to  submit 


To:  01 IveSNavy 

From:  MOSISSUSC-ISIF.ARPA 

Subject:  OK  New-Project.  12345  VFFT 

10:  12346 

P-Name:  VFFT 

Status:  New  project;  no  valid  CIF. 


Figu  re  1 2 :  MOSIS  response  acknowledging  new  project 


To:  MOSIS9USC-ISIF .  ARPA 

From:  OliveSNavy 

Subject:  Submit  for  CIF  check 


REQUEST:  SUBMIT 


ID:  12345 

P-PASSWORD:  Kazlboo 

SIZE:  2000  x  3000 

CIF-CHECKSUM:  931160  18320 

CIF: 

(LAP2818  ---  VFFT.CIF); 

(Symbol  VFFT ) ; 


DS  1  250  10; 

L  ND; 

W  20  960.-50  960.100; 
B  60  500  1030.80; 


E 

REQUEST:  END 


Figu re  1 3:  A  message  requesting  CIF  check 


To:  01 IveBNavy 

From:  MOSISeUSC-ISIF.ARPA 

Subject:  OK  Submit,  12345  VFFT 

IO:  12346 

P-Name :  VFFT 

Status:  Queued  for  CIF  check. 


Checksum:  931160  18320 


Figure  1 4:  MOSIS  acceptance  of  CIF  for  check 


To:  OllveSNavy 

From:  MOSIS8USC- ISIF . ARPA 

Subject:  OK  CIF-check,  12345  VFFT 

ID:  12345 

P-Name:  VFFT 

Status:  Valid  CIF;  NOT  queued  for  fabrication. 
Size:  2000  x  3000  microns 


Figu  re  1 5:  MOSIS  response:  valid  CIF 


To:  OllveSNavy 

From:  MOS I S0USC -ISIF. ARPA 

Subject:  Failed  CIF-check.  12345  VFFT 

IO:  12345 

P-Name:  VFFT 

Status:  Failed  CIF-check;  no  valid  CIF. 
Error(s)  found: 

ERROR:  Could  find  only  23  of  your  24  pads. 


Figure  1 6:  MOSIS  response:  failed  CIF  check 


Any  CIF  that  fails  a  CIF  check  is  deleted  from  the  MOSIS  database.  Therefore,  any  corrected  or 
revised  CIF  should  be  submitted  in  complete  form  for  checking  as  done  originally.  The  Submit 
request  may  be  used  many  times  for  correction  and  revision  of  CIF  before  the  project  is  queued  for 
fabrication. 

Users  who  have  difficulty  submitting  large  CIF  files  through  their  mail  systems  may  either  fragment 
their  CIF  and  submit  each  fragment  separately,  or  ask  MOSIS  to  use  FTP  for  direct  retrieval  of  the  CIF 
file.  Users  communicating  over  noisy  lines  should  use  CIF-CHECKSUM  to  protect  the  integrity  of 
design  files.  The  user  manual  contains  sections  documenting  CIF-FRAGMENT,  CIF-CHECKSUM, 
and  CIF-FTP-PATH. 

F.3.3.  Request  for  fabrication 

When  the  CIF  file  is  valid,  the  user  may  send  MOSIS  a  Fabricate  request  to  place  the  design  in  the 
fabrication  queue,  as  shown  in  Figure  17.  MOSIS  will  respond  with  acknowledgement  of  the 
Fabricate  request,  as  shown  in  Figure  18. 


To:  MOS I S9USC - IS I F . ARPA 

From:  OliveSNavy 

Subject:  Request  to  fabricate 

REQUEST:  FABRICATE 
10:  12345 

P-PASSWORD:  KazibOO 
REQUEST:  END 


Figu  re  1 7 :  A  message  requesting  fabrication  of  CIF 


To:  OliveSNavy 

From:  M0SIS8USC-ISIF . ARPA 

Subject:  OK  Fabricate,  12345  VFFT 

ID:  12345 

P-Name:  VFFT 

Status:  Queued  for  fabrication. 
Size:  2000  x  3000  microns 


Figu  re  1 8 :  MOSIS  response  -  CIF  queued  for  fabrication 


F.3.4.  Modifying  requests 

If  a  user  needs  to  update  the  parameters  of  a  project,  cancel  a  request  for  fabrication,  delete  a  CIF 
file,  or  withdraw  a  project  from  the  MOSIS  system  entirely,  the  following  sections  may  be  referenced 
in  the  user  manual  (Appendix  III): 

C.6  The  UPDATE  Request  C.7  The  DELETE-CIF  Request 

C.8  The  CANCEL-FABRICATE  Request  C.9  The  CANCEL-PROJECT  Request 

F.3.5.  Fabrication  announcement 

Closing  dates  for  upcoming  runs  are  posted  in  the  run  schedule  file  (available  online  from  MOSIS,  see 
Figure  10).  After  a  run  is  closed,  MOSIS  creates  the  mask  pattern  tapes  and  sends  them  to  the  mask 
fabricator  to  begin  the  fabrication  process.  MOSIS  informs  the  user  of  his  project  fabrication,  as 
shown  in  Figure  19. 


To:  OllveSNavy 

From:  MOSIS0USC-ISIF. ARPA 

Subject:  Being  fabricated:  12345  VFFT 

Status:  Being  fabricated. 

Fab-10:  M79HE01 

The  Fab-10  indicates  on  which  die  of  run  M79H  (Honcho)  the  project 
is  fabricated. 

From  now  on  please  obtain  status  and  scheduling  Information 
concerning  this  run  by  using  the  following  MOSIS  request: 

REQUEST:  INFORMATION 
TOPIC:  M79H.STS 
REQUEST:  END 

Thank  you  very  kindly. 

The  MOSIS  Project 


Figure  19:  MOSIS  informs  user  of  project  fabrication 

The  fabrication  message  to  the  user  includes  a  new  entity,  a  Fab-ID,  that  uniquely  identifies  this 
project  on  this  particular  fabrication  run.  A  Fab-ID  (the  illustrated  one  is  "M79HED1")  consists  of 
three  parts:  a  four-character  run  ID  ("M79H"),  a  two-letter  die  ID  ("ED"),  and  a  project  number  on  the 
die  ("1 ");  the  project  number  ranges  from  one  up  to  the  number  of  projects  on  the  given  die.  A  run  is 
also  given  a  nickname  ("Honcho")  for  easy  reference  (and  for  fun). 

A  run  name  is  assigned  by  MOSIS  to  each  distinct  mask  set  that  is  used  to  fabricate  a  set  of  (identical) 
wafers.  On  occasion,  MOSIS  refabricates  a  die  on  another  run.  When  this  happens,  the  user  receives 
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a  second  "being  fabricated”  message  with  a  new  Fab-ID,  which  usually  differs  from  the  first  one  only 
in  the  run  name.  Refabrication  may  occur  for  any  of  a  number  of  reasons,  most  commonly  that  the 
MOSIS  service  has  decided  to  back  up  a  run  with  another  run,  usually  with  a  different  fabricator. 

F.3.6.  Status  request 

A  user  may  request  a  status  report  on  his  project  at  any  time  during  the  fabrication  process.  The 
status  of  all  of  the  projects  on  the  same  run  is  identical.  Therefore,  the  preferred  way  of  requesting 
status  information  is  by  requesting  the  status  of  the  run  rather  than  the  status  of  the  individual  project, 
as  shown  in  Figure  20. 


To:  M0SIS8USC- ISIF . ARP A 

From:  OllveSNavy 

Subject:  Project  status  request 

REQUEST:  INFORMATION 
TOPIC:  M79H.STS 
REQUEST:  END 


Figure  20:  A  message  requesting  status  of  project 

F.3.7.  Probing  results  request 

When  wafer  fabrication  is  complete,  wafers  are  first  probed  by  the  vendors  to  assure  that  their 
specifications  have  been  met  and,  if  so,  are  shipped  to  MOSIS.  MOSIS  then  performs  DC 
parametrical  probing  using  its  own  set  of  test  structures  to  assure  that  the  wafers  indeed  meet  the 
MOSIS  specifications.  The  results  of  this  probing  are  posted  online.  Users  may  retrieve  probe  results 
(parameters),  as  shown  in  Figure  21 . 


To:  MOS IS8USC - 1 S I F . ARPA 

From:  OllvaSNavy 

Subject:  Request  for  parameters 

REQUEST:  Information 
TOPIC:  M79H.PRM 
REQUEST:  END 


Figure  21 :  A  message  requesting  parameters 
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F.3.8.  Delivery  of  parts 

When  device  packaging  is  complete,  MOSIS  sends  the  user  bonded  chips  with  information  relating  to  | 

the  project.  This  information  package  consists  of  a  cover  letter,  an  acknowledgement  of  receipt  of 
devices  (to  be  signed  and  returned  to  the  MOSIS  Project  via  US  Mail),  a  wire  bonding  diagram  for 
custom  frame  projects  (showing  correspondence  of  the  user’s  pads  to  the  pins  of  the  package),  and  a 
summary  of  the  DC  parametric  measurements  collected  during  wafer  characterization  by  MOSIS 
before  packaging.  Appendix  I  is  an  example  of  the  information  package. 

F.3.9.  Submittal  of  reports  —  be  specific 

Finally,  each  user  should  provide  MOSIS  with  a  project  report,  as  shown  in  Figure  22.  Comprehensive  I 

reports  should  be  sent  as  quickly  as  possible.  In  addition  to  its  own  quality  control,  MOSIS  considers 
these  reports  for  evaluation  of  vendors. 


It  is  particularly  important  that  all  performance  and  yield  data  be  reported  separately  for  each 
fabrication  of  a  project.  Each  report  should  clearly  identify  both  the  ID  and  Fab-ID  of  the  project. 


Reports  should  specify  the  die  site  location(s)  of  each  project  as  well  as  the  number  of  the  wafer  from 
which  the  devices  were  packaged;  this  information  helps  MOSIS  locate  fabrication  defects.  The  site 
location  of  each  die  can  be  found  in  the  top  right-hand  corner  of  the  die  when  viewed  under  a 
microscrope;  the  wafer  number  is  on  each  device  label. 


To:  M0S1S8USC-ISIF .  AR'PA 
From:  011ve8Navy 

Subject:  REPORT  on  12345  M79HED1  VFFT 

REQUEST:  REPORT 
ID:  12345 
P-Name:  VFFT 
Fab-ID:  M79HED1 
P-P:  Kaziboo 
REPORT: 

We  received  25  bonded  devices  for  this 
project.  Only  23  of  them  were  found  to  be 
fully  operational  at  25Mhz. 

Both  defective  dies  have  the  same  problem, 
and  both  came  from  site  No.  43  on  wafers 
#2  and  #5.  Therefore,  we  suspect  that  this 
is  a  mask  defect. 

REQUEST:  END 


Figure  22:  A  project  report  to  MOSIS 


(G)  New  and  Future  Services 
G.1 .  Calma 

The  MOSIS  Project  will  soon  add  Calma  (GDS  II  Stream)  Format  as  an  alternative  to  CIF  for  the 
submission  of  artwork. 

G.2.  Functional  Screening 

In  the  near  future,  MOSIS  will  be  able  to  do  functional  screening  at  wafer  probe  for  users  requiring 
large  numbers  of  parts.  The  purpose  of  this  screening  will  be  to  reduce  the  probability  of  packaging 
bad  parts  and  to  avoid  performing  exhaustive  functional  and  performance  testing.  Users  will  be 
asked  to  specify  the  test  code  in  terms  of  a  language  named  SIEVE,  which  is  now  under  review  by  the 
MOSIS  community. 

G.3.  Library  Expansion 

The  MOSIS  library  will  soon  contain  a  set  of  pads  for  CMOS/Bulk  that  will  be  designed  to  provide  a 
very  strong  barrier  against  latch-up.  For  this  latch-up  barrier  to  be  effective,  it  is  necessary  that  the 
chip  internal  circuitry  be  completely  enclosed  by  a  well  barrier.  When  I/O  pads  do  not  fully  enclose 
the  circuit  area,  a  special  barrier  cell  must  be  used  to  complete  the  barrier  enclosure. 

When  a  general  interconnect  service  can  be  initiated,  the  library  will  be  extended  to  include  major 
logic  functions,  computational  functions  (multipliers,  etc.),  and  memory. 

G.4.  Pad  Router 

In  the  near  future,  MOSIS  will  offer  automatic  placement  and  routing  to  pads  for  nMOS  projects. 
Users  will  submit  port  information  (i.e.,  ports,  their  position,  layer,  width,  and  pad  requirement)  in  a 
predetermined  format  and  will  receive  CIF  corresponding  to  pad  routing  and  pads  which  they  can 
then  merge  with  their  geometry.  Users  always  have  the  option  to  either  accept  or  reject  the  MOSIS 
pad  routing. 

G.5.  Standard  Project  Frames 

The  MOSIS  service  has  introduced  the  option  of  using  standard  project  frames  for  packaging:  a 
rectangular  area  of  a  fixed  size  with  a  fixed  set  of  bonding  pad  locations  around  the  periphery  of  the 
rectangle.  Figure  3  illustrates  three  standard  frame  projects.) 

The  circuitry  in  the  remainder  of  the  frame,  the  routing  of  pad  connections,  and  the  choice  of  pad 
types  at  each  of  the  fixed  locations  are  specified  by  the  user.  Details  of  this  alternative  to  custom  pad 
frames  is  found  in  Section  H.1.2  of  the  MOSIS  user  manual  (Appendix  III). 


Appendix  I 

Information  Package 


Figures  1-1 ,  1-2,  1-3  and  1-4  are  examples  of  (he  transmittal  paperwork  sent  to  designers  along  with 
packaged  parts.  Please  note  that  the  probing  results  enclosed  are  also  available  online  (see  Section 
F.3.7)  and  that  bonding  diagrams  are  sent  for  custom  frame  projects  only. 


Ms.  o.  Oyl 
OP-9876 
NAS  Poseidon 
Massachusetts  02177 


Dear  M79H  Participant: 


Enclosed  please  find  25  packaged  chips  of  your  project: 


10:  12345 
P-Natne:  VFFT 
Fab-IO:  M79HE01 


Attached  is  a  bonding  map  for  the  project.  The  die  substrate, 
indicated  by  an  "X",  is  typically  connected  to  pin  1,  but  may  be 
connected  to  a  different  pin  or  left  unconnected.  Be  sure  to 
check  your  bonding  map. 


Attached  are  the  electrical  parameters  for  the  run. 


The  MOSIS  group  is  very  much  interested  in  receiving  feedback 
concerning  the  projects,  particularly  regarding  performance, 
problems  encountered,  and  If  there  are  problems,  what  they  are 
(mask,  fabrication,  bonding,  silicon  defect,  etc.).  Please  send 
your  REPORT,  either  via  netmail  to  MOSIS,  or  via  US  mall  to: 


The  MOSIS  Project 
USC/Informatlon  Sciences  Institute 
4676  Admiralty  Way 

Marina  del  Rey,  California  90292-6696 


Kindly  Include  In  the  subject  line  of  your  REPORT  the  Fab-IO  and 
P-NAME  of  your  project. 


Sincerely, 


The  MOSIS  Project 


Figu re  I- 1 :  Project  transmittal  letter 


Jl'A.W-VA 
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Dear  Project  recipient: 


Because  of  contract  requirements,  we  must  receive  written 
acknowledgement  of  every  project  you  receive  from  us. 

Kindly  acknowledge  receipt  of  your  project  by  signing  and  dating 
the  form  below,  and  return  this  form  to  us  as  soon  as  possible. 
The  back  of  this  form  is  preaddressed  so  that  you  may  fold  and 
seal  it  with  our  address  on  the  outside  ready  for  mailing. 

Thank  you  for  your  cooperation  and  understanding. 

Sincerely. 

The  MOSIS  Project 


PLEASE  RETURN  THIS  FORM.  WITH  CORRECTIONS.  IF  ANY,  TO: 

The  MOSIS  Project 
USC/Informatlon  Sciences  Institute 
4676  Admiralty  Way 
Marina  del  Rey,  CA  90292-6695 

I  hereby  acknowledge  receipt  of  the  below-described  bonded 
project(s) : 

Quantity:  25 

ID:  12345 
P-Name:  VFFT 
Fab-IO:  M79HE01 

Signed: 


Date: 


Ms.  0.  Oyl 
OP-9876 
NAS  Poseidon 
Massachusetts  02177 


Figure  1*2:  Device  acknowledgement  receipt 


M79H  ISI  Accutest,  NM0S/MC2,  4u.  3in.  (level  •  2) 
10  wafers  probed,  total  number  of  dies:  330 


EXECUTIVE  SUMMARY 
DC  Parametric  Measurements 


Tst 

Mean 

Slg/Mean 

Count 

Sigma 

64  329 

0.949 

0.02 

2 . 31X 

(V) 

Vth  Large  Enh  (Vbs*0) 

65  329 

-3.300 

0.08 

-2 .37% 

(V) 

Vth  Large  Oep  (Vbs*0) 

19  329 

6.191 

0.22 

3.63X 

(urn) 

Metal  Width  Marrow 

104  329 

3.987 

0.42 

7 . 13X 

(urn) 

Poly  Width  Narrow 

107  328 

3.973 

0.15 

3.78X 

(urn) 

Dlff  Width  Narrow 

85  328 

1.628 

0.04 

2.  SOX 

(V) 

Vlnv  ( K8) 

89  324 

1.794 

0.06 

3.16X 

(V) 

Vlnv  (K4) 

100  292 

4.901 

0.47 

9.58X 

(MHz) 

Ring  Freq  5.0V 

10  330 

14.478 

5.34 

36.90X 

(UA) 

Ids  W2xL10  Oep  Vd>6 

11  330 

5.940 

3.61 

60.79X 

(uA) 

Ids  W2xL10  Oep  Vd*6 

12  329 

39.584 

2.30 

5.80X 

(uA) 

Ids  W4xL10  Dep  Vd*5 

13  329 

22.966 

1.81 

7.87X 

(UA) 

Ids  W4xL10  Oep  Vd*5 

14  330 

95.068 

10.02 

10.54X 

(UA) 

Ids  Min  Dep  Vd*5 

15  330 

57.445 

8.02 

13.96X 

(UA) 

Ids  Min  Dep  Vd*5 

16  323 

0.008 

0.00 

15.42X 

(UA) 

Ids  Min  DepPas  Vd=5 

30  329 

0.053 

0.01 

1S.43X 

(UA) 

Ids  L2xW10  Enh  Vd*5.0 

31  330 

611.183 

53.63 

8.77X 

(uA) 

Ids  L2xW10  Enh  Vd«4.0 

32  329 

502.632 

44.11 

8.78X 

(UA) 

Ids  L2xW10  Enh  Vd=4.0 

33  330 

161.255 

14.38 

8.92X 

(UA) 

Ids  L2xW10  Enh  Vd*0.4 

41  329 

0.026 

0.04 

164. 14X 

(UA) 

Ids  L2xW10  Dep  Vd=6 

51  330 

91.646 

9.57 

10.45X 

(ua) 

Ids  min  enh  vd*4.0 

62  330 

46.625 

5,97' 

12.81X 

(ua) 

Ids  min  enh  vd*4.0 

53  328 

27.637 

1.91 

6.91X 

(ua) 

ids  min  enh  vd'0.4 

End  of  executive 

summary 

COMPLETE 

TEST  RESULTS 

Tst 

Mean 

Slg/Mean 

Count 

Sigma 

1  330 

-2.840 

0.17 

-6.99X 

(V) 

Vth  Dep  Length  10L 

2  328 

0.220 

0.02 

8.33X 

(ua/v) 

Slope  Dep  Width  2L 

3  330 

-3.076 

0.07 

-2.25X 

(V) 

Vth  Dep  Width  4L 

. . .etc. . 

Figu  re  1*3:  DC  parametric  measurements  of  MOSIS  run 


§  0  B  §  0  B 
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M79HED1 


BOND  <o  CHIPS 

Figure  1-4:  Custom  project  frame  bonding  diagram 
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Appendix  il 

MOSIS  Information  Topic 

Information  about  MOSIS  is  available  on  the  following  topics: 

Toole  name  Topic 

TOPICS  This  information. 

GENERAL  Information  on  service  provided,  how  to  obtain  authorization  to  use  MOSIS. 

USER-MANUAL  Details  on  the  form  of  request  messages  to  the  MOSIS  system. 

TEMPLATES  A  listing  of  the  various  MOSIS  requests  in  the  form  of  templates  that  may  be  filled 
in  and  sent  to  MOSIS  as  needed;  especially  handy  for  novice  or  casual  users. 

SCHEDULE  The  schedule  for  open  periods  for  submittal  of  designs  to  MOSIS,  for  fabrication, 
and  other  significant  dates. 

TECHNOLOGY  Summarizes  the  documentation  on  technology  that  MOSIS  currently  supports, 
including  where  to  find  design  rule  information  for  specific  technologies. 

OVERSIZE  Documentation  on  the  MOSIS  fabrication  of  oversize  projects,  including 

particularly  when  such  projects  will  be  fabbed. 

QUANTITY-PARTS 

Information  on  how  to  go  about  requesting  large  quantities  of  any  one  project. 

STATUS  Status  information  about  current  MOSIS  runs  (i.e.,  those  runs  not  completely 

distributed  to  MOSIS  users). 

ALL-RUNS  Status  of  all  runs  including  those  already  completely  distributed  to  their  users. 

NEWS  Information  on  recent  changes  to  the  MOSIS  system. 

ANNOUNCEMENTS 

Copies  of  current  MOSIS  announcements;  also  sent  to  MOSIS  liaisons. 

DIRECTORY  A  directory  listing  of  the  information  files  currently  available  through  the 
INFORMATION  request  (this  listing  is  updated  daily). 
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NMOSDR 


CB3UDR.CIF 


run.STS 


run.PRM 


LIBRARY 


The  NMOS  process  design  rules  which  MOSIS  supports,  including  buried  contact 
rules  (similar  files  exist  for  other  technologies;  consult  TOPIC:TECHNOLOGY  for 
details). 

The  CMOS-bulk  3-micron  design  rules,  as  plottable  CIF  (the  prose  description  is 
presently  available  only  in  hard-copy  form,  available  via  an  ATTENTION  request). 

The  status  of  the  run  named  "run”  (the  name  of  the  run  for  a  particular  fabricated 
device  is  the  first  four  characters  of  its  "Fab-ID”). 

The  electrical  parameters  for  the  run  named  "run." 

Introductory  information  on  the  MOSIS  cell  library. 


To  obtain  information  about  MOSIS,  send  a  message  via  ARPANET  to  MOSIS@USC-ISI,  or  via 
TELEMAIL  to  MOSIS/USCISI,  which  includes  the  following  lines: 


REQUEST: 

TOPIC: 

REQUEST: 


INFORMATION 
topic  name 
END 


where  "topic  name"  is  one  of  the  names  given  above.  MOSIS  will  reply  to  the  message  with 
information  on  the  topic  requested. 
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The  MOSIS  Project 
USC/ISI 


Major  revision:  1  March  1984 


MOSIS 

USER  MANUAL 


30 


(A)  Overview:  interaction  with  MOSIS 

All  communication  between  users  and  MOSIS  is  carried  out  by  net  messages,  either  over  the 
ARPANET  system  or  TELEMAIL. 

Typically,  an  authorized  user  first  requests  to  submit  a  project  for  fabrication  by  sending  the 
NEW-PROJECT  message  to  MOSIS. 

Upon  acceptance  of  a  project,  MOSIS  assigns  a  unique  identification  to  it  and  communicates  this  ID 
to  the  user  by  a  net  message. 

After  receiving  the  ID,  the  designer  uses  the  FABRICATE  message  to  submit  a  CIF  file  to  MOSIS  for 
fabrication. 

If  the  user  wants  only  to  check  the  validity  of  the  CIF  file,  he  may  submit  it  for  CIF  check  by  using  the 
SUBMIT  message.  Once  he  gets  the  results  of  this  check,  he  may  decide  to  either  fabricate  the 
project  or  delete  the  CIF  file. 

The  FABRICATE  message  is  used  to  request  fabrication.  The  DELETE-CIF  message  is  used  to  delete 
the  CIF  file  without  cancelling  the  project. 

After  deleting  the  CIF  file,  the  user  may  submit  a  new  design  by  again  using  either  the  SUBMIT  (or 
FABRICATE)  message. 

After  the  project  is  submitted  for  fabrication,  it  is  incorporated  into  queues. 

If,  after  issuing  the  FABRICATE  message,  the  user  decides  to  cancel  the  fabrication,  he  may  send  the 
CANCEL-FABRICATE  message;  however,  after  a  certain  stage  it  is  too  late  to  stop  the  fabrication 
process. 

If  at  any  time  the  user  wants  to  withdraw  his  project,  the  CANCEL-PROJECT  message  is  used. 

In  addition  to  the  above  messages,  there  are  also  messages  for  requesting  information  about  MOSIS, 
the  status  of  projects,  changing  parameters,  and  more.  All  of  these  are  described  in  this  document. 

Each  message  to  MOSIS  carries  various  parameters  which  are  described  in  Section  D,  "REQUESTS 
AND  PARAMETERS". 


(B)  Administration 

B.1 .  Access  Control,  Authentication,  and  Accounting 

There  are  several  features  for  controlling  user  access  to  MOSIS  services. 

Access  control  is  based  on  information  entered  into  the  MOSIS  Authentication  Data  Base  (ADB)  by 
the  MOSIS  staff  (rather  than  by  users  via  net  messages). 

This  information  contains  the  list  of  designers  authorized  to  use  MOSIS  services  and  includes  their 
affiliation,  individual  passwords,  and  the  designation  of  the  account  to  be  charged  for  each  designer. 

The  use  of  passwords  is  similar  to  the  use  of  passwords  in  conventional  time-sharing  systems.  The 
designer  password  (D-PASSWORD)  is  distinguished  from  the  project  password  (P-PASSWORD)  as 
described  later  in  this  document. 

A  designer  may  have  more  than  one  account,  with  unique  passwords  for  each. 

In  order  to  accept  a  user,  MOSIS  must  have  in  its  ADB  the  exact  combination  of  the  AFFILIATION, 
ACCOUNT,  designer-name  (D-NAME),  and  designer-password  (D-PASSWORD). 

The  ACCOUNT  is  always  treated  as  the  extension  of  the  AFFILIATION.  Hence,  "VLSI"  of  ISI  and 
"VLSI"  of  MIT  are  different  accounts.  The  actual  accounts  are  defined  by  both  the  AFFILIATION  and 
the  ACCOUNT  fields. 

In  addition  to  the  above  parameters,  a  designer  must  assign  a  password  to  each  of  his  projects 
(P-PASSWORD).  Hence  a  designer  may  invite  a  colleague  to  work  on  a  particular  project  and  be  aole 
to  give  him  access  to  that  project  only. 

To  submit  a  project  to  MOSIS,  the  user  must  first  issue  an  initial  NEW-PROJECT  message  with  his 
name  (D-NAME),  affiliation,  designer-password  (D-PASSWORD),  and  account  designation.  In 
addition,  he  must  assign  this  particular  project  a  project-name  (P-NAME)  and  a  project-password 
(P-P  ASSWORD)  of  his  choice. 

In  all  future  communications  about  this  project,  the  user  must  use  both  the  P-PASSWORD  and  the  ID 
(assigned  by  MOSIS). 
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B.2.  Budget  Control  and  Other  Organizational  Issues 

***The  following  has  not  yet  been  implemented*** 

MOSIS  as  described  above  models  the  designers  as  belonging  to  a  space  which  is  organized  only  by 
their  affiliations  and  accounts. 

MOSIS  will,  at  some  future  time,  issue  charges  for  most  of  its  operations.  Neither  the  charging  units 
nor  the  charging  policy  have  yet  been  defined. 

The  Authentication  Data  Base  (ADB)  will  be  augmented  to  include  budget  information  for  each 
account  and  each  (AFFILIATION, ACCOUNT, D-NAME,D-PASSWORD)  quadruplet. 

Each  MOSIS  charge  will  be  applied  against  both  the  designer's  budget  and  the  account's  budget. 
MOSIS  will  not  perform  operations  which  result  in  overspending  of  these  budgets. 

The  administrator  of  an  account  may  "oversell"  it  by  assigning  to  his  designers  budgets  that  total 
more  than  the  entire  budget  of  the  account.  This  allows  flexibility  as  long  as  the  average  project  size 
does  not  exceed  the  expected  one;  however,  this  overbooking  may  be  abused  by  prolific  designers 
who  share  the  account. 

Passwords  will  also  be  assigned  to  both  organizations  (ORG-PASSWORD)  and  accounts 
(ACC-PASS WORD).  The  administrator  of  the  organizations  (i.e.,  "affiliations")  and  accounts  must 
use  them  in  order  to  obtain  the  accounting  information  regarding  the  projects  that  are  charged  to 
them. 

The  format  of  requests  for  accounting  information  has  not  yet  been  defined. 

Please  note  that  the  ORG-PASSWORD  and  ACC-PASSWORD  allow  access  to  the  accounting 
information  regarding  individual  projects  but  not  to  the  technical  data  (e.g.,  CIF).  Also,  individual 
designers  will  be  able  to  get  the  accounting  information  for  their  projects  by  using  certain  requests. 


(C)  Requests  to  MOSIS 

The  following  are  detailed  descriptions  of  MOSIS  requests,  including  MOSIS  actions  and  responses. 

C.1 .  The  INFORMATION  Request 

This  request  asks  MOSIS  for  information  on  specific  topic(s);  e.g.,  how  to  make  requests  or  how  to 
retrieve  schedules.  MOSIS  will  respond  with  information  on  that  topic  or,  if  there  is  none,  wiih  a 
message  describing  the  topics  for  which  information  is  available. 

The  information  request  is  specified  by  the  TOPIC  parameter.  Several  TOPIC  parameters  may  be 
included  in  one  REQUEST.  This  request  may  also  include  the  ATTENTION,  BYTE-LIMIT,  or 
LINE-LIMIT  parameters.  All  other  parameters  will  be  ignored. 

•  The  topic  "GENERAL"  will  retrieve  information  on  how  to  become  a  MOSIS  user. 

•  The  topic  "TOPICS"  will  retrieve  a  list  of  all  topics  on  which  information  is  available. 

•  The  topic  "MANUAL"  will  retrieve  this  document. 

•  The  topic  "SCHEDULE"  will  retrieve  the  current  MOSIS  run  schedule. 

•  The  topic  "TECHNOLOGY"  will  retrieve  information  on  technologies  supported  by 
MOSIS. 

•  The  topic  "NEWS"  will  retrieve  information  on  recent  changes  to  the  MOSIS  service. 

•  The  topic  "XXXXXX.YYY"  will  retrieve  the  file  having  that  name,  if  any,  from  the  MOSIS 
information  service. 

C.2.  The  LIBRARY  Request 

This  request  asku  for  information  from  the  MOSIS  library  and  may  be  used  to  retrieve  information  on 
the  use  of  the  library,  the  availability  of  designs  in  the  library,  and  how  to  retrieve  particular  designs 
from  the  library.  The  specific  request  is  specified  by  the  TOPIC  parameter. 

Please  note  that  this  request  may  include  the  TOPIC  parameter  (which  may  be  repeated  for  several 
topics)  or  the  ATTENTION,  BYTE-LIMIT,  or  LINE-LIMIT  parameters.  All  other  parameters  will  be 
ignored.  The  topic  "LIBINFO"  will  retrieve  information  on  using  the  MOSIS  library.  The  LIBINFO  file 
will  supply  information  on  the  meaning  of  various  files  and  extensions. 

The  topic  "CATALOG"  will  retrieve  names  of  all  files  which  are  available  in  the  library.  The  CATALOG 
will  supply  information  on  various  available  designs  and  will  point  to  the  appropriate  name, 
XXXXXX.YYY.  ‘  The  topic  "XXXXXX.YYY"  will  retrieve  the  file  having  that  name,  if  any. 
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C.2.1 .  Mail  size  limits 

For  the  convenience  of  users  whose  host  machines  enforce  particular  limits  on  the  size  of  incoming 
mail,  MOSIS  accepts,  in  INFORMATION  and  LIBRARY  requests,  two  parameters:  "BYTE-LIMIT"  and 
"LINE-LIMIT".  MOSIS  interprets  these  two  parameters  as  limits  on  the  number  of  bytes  and  number 
of  lines,  respectively,  in  the  body  of  the  message(s)  that  MOSIS  sends  back  to  the  user  requesting  the 
information  or  library  file(s).  Any  information  or  library  file  that  is  larger  than  one  or  the  other  of  the 
user-specified  limit(s)  will  be  sent  to  the  user  in  as  many  messages  as  required.  The  MOSIS  user  may 
specify  either  or  both  limits  in  order  to  meet  host  machine  requirements. 

Please  note  that  these  are  REQUEST  parameters  (NOT  message  header  parameters)  and  must 
appear  WITHIN  each  request  (i.e.,  following  the  "REQUEST:"  line).  An  example: 

REQUEST:  INFORMATION 

TOPIC:  CB3UDR.CIF 

BYTE-LIMIT:  10000 

REQUEST:  END 

MOSIS  uses  these  limits  for  its  own  text  without  taking  into  account  the  "message  header"  lines 
required  for  network  mail;  users  whose  host  machines’  limits  include  message  header  lines  should 
specify  to  MOSIS  limits  that  are  at  least  500  bytes  and  10  lines  smaller  than  their  host-enforced  limits. 

C.3.  The  NEW-PROJECT  Request 

This  is  the  first  request  a  user  makes  to  MOSIS.  It  establishes  a  proposed  project,  requests  a  project 
ID  from  MOSIS,  tells  MOSIS  who  is  proposing  the  project,  and  specifies  some  of  the  expected 
parameters  of  the  final  project  design. 

MOSIS  will  acknowledge  this  request  with  a  message  giving  the  system-assigned  ID  for  the  project. 
This  ID  must  be  used  in  all  future  requests  to  MOSIS  concerning  the  project. 

In  this  request  the  designer  has  to  identify  himself  by  providing  his  affiliation,  his  name  (D-NAME),  his 
password  (D-PASSWORD),  and  his  account.  MOSIS  compares  these  parameters  with  the  ones  in  its 
access  table  and,  if  an  exact  match  is  found,  this  project  is  accepted  and  an  identification  (ID)  is 
issued  for  it.  The  message  must  also  include  both  a  net  address(es)  to  which  MOSIS  should  direct  all 
of  its  messages  about  this  project  and  a  mailing  address  to  which  any  artifacts  (e.g.,  fabricated 
devices)  should  be  mailed. 

This  message  must  also  include  a  password  (P-PASSWORD),  a  short  name  (P-NAME),  and  a 
description  of  the  project.  The  designer  may  assign  any  random  password  to  each  of  his  projects.  No 


messages  about  this  project  will  be  accepted  by  MOSIS  unless  they  contain  both  the  10  as  assigned 
by  MOSIS  and  the  password  as  assigned  by  the  designer. 

Several  other  optional  parameters  may  be  incorporated  in  this  message.  These  include  packaging 
parameters  for  the  project  and  the  value  of  lambda  used  in  the  project’s  CIF  file.  In  addition,  as  in 
most  requests,  comments  may  be  added  and  manual  attention,  special  handling,  and  bonding 
instructions  may  be  requested. 

Most  of  the  parameters  specified  in  this  message  may  be  modified  later  by  redefining  them.  The  ones 
which  cannot  be  changed  through  messages  in  the  lifetime  of  the  particular  project  are  the  designer’s 
affiliation,  name  (D-NAME)  and  account,  passwords  (D-PASSWORD  and  P-PASSWORD),  and 
mailing  address  -  these  can  only  be  modified  manually  by  the  MOSIS  crew.  These  parameters  are 
designated  with  an  asterisk . in  the  table  of  required  parameters  in  Section  D.3  in  this  document. 

C.4.  The  SUBMIT  Request 

This  request  is  used  for  submitting  a  CIF  file  to  MOSIS.  It  implicitly  asks  MOSIS  to  perform  a  CIF 
validation  check,  to  compute  the  size  of  the  project  (aka  "MBB”),  and  to  count  the  pads.  It  may  be 
issued  only  after  the  project  has  been  accepted  by  MOSIS  and  assigned  an  ID.  This  request  must 
always  include  the  ID  of  the  project  and  its  password  (P-PASSWORD).  It  must  also  contain  the  size 
and  the  technology  of  the  project,  unless  these  were  specified  earlier. 

Optional  parameters  for  this  request  are  the  name  of  the  project  (P-NAME),  project  description, 
designer's  net  address,  value  of  lambda,  and  packaging  parameters.  These  parameters  are  either 
new  entries  to  the  MOSIS  data  base  or  updates  to  previously  supplied  parameters.  In  addition,  as  in 
most  requests,  comments  may  be  added  and  manual  attention,  special  handling  and  bonding 
instructions  may  be  requested. 

If  all  parameters  needed  for  this  request  are  present  in  satisfactory  form,  MOSIS  will  accept  the  CIF 
specification  for  validation  check  and  will  send  an  initial  acknowledgment  to  the  designer’s  net 
address.  MOSIS  will  then  place  the  CIF  specification  in  a  queue  of  CIF  designs  for  validation  check  at 
a  later  time. 

The  CIF  may  be  specified  either  directly  in  the  message  or  by  means  of  a  CIF-FTP-PATH.  CIF  may 
also  be  sent  in  fragments  in  several  messages.  Please  see  Sections  F  and  G  in  this  document  for 
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After  performing  the  CIF  check,  MOSIS  will  send  a  second  message  detailing  (1 )  CIF  errors  and/or 
warnings,  if  any,  and  (2)  the  actual  (computed)  size  of  the  project.  If  MOSIS  finds  this  CIF  file 
acceptable,  it  keeps  the  file  and  notifies  the  designer  via  net  mail.  However,  if  errors  are  found, 
including  CIF  e-rors,  standard  frame  mismatch,  size  mismatch,  or  insufficient  number  of  bonding 
pads  compared  to  the  specification,  MOSIS  deletes  the  CIF  file  and  notifies  the  designer  via  net  mail. 

Size  mismatch  is  a  gross  mismatch  between  the  project  size  supplied  by  the  designer  (in  the  SIZE 
parameter)  or  implied  by  the  standard  frame  and  the  one  computed  by  the  MOSIS  CIF  check.  A  gross 
mismatch  is  an  error  greater  than  some  epsilon  in  either  the  horizontal  or  the  vertical  dimension  of  the 
project  (the  value  of  epsilon  is  specified  in  the  "Technology"  information  document).  There  is  one 
exception:  if  the  size  estimate  with  dimensions  transposed  is  within  epsilon  of  the  actual  project  size 
in  either  dimension,  then  there  is  no  size  mismatch. 

For  a  custom  frame  project  with  a  specified  pad  count,  if  the  user  specifies  that  there  are  more  pads 
than  MOSIS  finds,  MOSIS  will  reject  the  CIF.  If  the  user  specifies  that  there  are  fewer  pads  than 
MOSIS  finds,  MOSIS  will  issue  a  warning  to  the  user. 

When  MOSIS  receives  a  SUBMIT  request  for  a  project  which  already  has  a  valid  CIF  file,  the  old  CIF 
file  is  deleted  and  replaced  with  the  new  one.  If  the  new  fife  is  not  found  valid,  then  it  is  deleted  too, 
leaving  the  project  without  a  valid  CIF  file.  A  valid  CIF  file  is  a  file  without  fatal  CIF  size  or  pad  errors, 
although  it  may  contain  other  errors  such  as  logic  errors  or  design  rule  violations. 

Please  note  that  only  error-free  CIF  files  are  retained  by  MOSIS;  a  project  may  have  either  a  valid  CIF 
file  or  no  CIF  file  at  all. 

MOSIS  considers  all  valid  CIF  files  ready  for  fabrication  and  expects  a  subsequent  FABRICATE 
request  to  follow  shortly.  MOSIS  will  delete  a  CIF  file  when  a  fabrication  request  for  that  file  has  not 
been  received  within  a  certain  time  period.  It  is  possible  to  include  the  SUBMIT  request  in  the 
FABRICATE  request,  as  described  below. 

C.5.  The  FABRICATE  Request 

Typically,  this  is  the  final  request  the  user  makes  concerning  any  particular  design.  It  specifies  that 
the  user  is  satisfied  with  the  design  and  is  willing  to  have  it  fabricated  in  silicon  according  to  the  CIF 
file  contained  in  either  the  last  SUBMIT  request  or  this  current  FABRICATE  request.  This  request 
places  the  project  in  a  queue  of  projects  awaiting  fabrication  for  the  specified  TECHNOLOGY.  Thus, 
the  sooner  this  request  comes  in,  the  sooner  the  project  will  be  fabricated.  The  ID  and  P-PASSWORD 


are  mandatory  parameters  of  this  request.  Many  other  parameters  are  optional  for  this  request.  In 
addition,  as  in  most  requests,  comments  may  be  added  and  manual  attention,  special  handling,  and 
bonding  instructions  may  be  requested. 

As  with  the  SUBMIT  request,  MOSIS  acknowledges  the  receipt  of  the  CIF  in  the  first  response 
message  and  supplies  details  of  the  CIF  check  in  the  second  response  message.  MOSIS  will  send 
additional  messages  as  necessary  detailing  various  aspects  of  the  fabrication  process  (e.g.,  expected 
date  of  completion  of  fabrication).  After  a  successful  FABRICATE  request  no  further  SUBMIT  or 
FABRICATE  requests  may  be  issued  for  this  project  unless  a  CANCEL-FABRICATE  request  has  been 
issued  and  accepted  beforehand. 

C.5.1 .  Changing  the  scale  of  designs 

When  a  run  is  assembled  (say,  for  lambda  equal  to  2.0  micron)  and  there  are  pending  projects  with 
other  values  of  lambda,  projects  with  larger  values  of  lambda  (say  2.5  microns)  may  be  included  in  the 
run  after  being  scaled  down  (by  2.0/2.5  here)  if  their  MIN-LAMBOA  is  set  to  2.0  microns  or  less. 
Otherwise,  they  may  be  included  without  any  scale  change,  if  there  is  enough  room  for  them. 

Projects  with  lower  values  of  lambda  (say  1.5  microns)  would  be  included  only  after  scaling  them  up 
(by  2.0/1. 5  here),  only  if  their  MAX-LAMBDA  was  specifically  used  to  allow  that  (here  by  setting  it  to 
be  at  least  2.0). 

Please  note  that  whenever  the  designer  allows  a  change  of  scale  it  is  his  responsibility  that  the  scaled 
design  is  functional  from  both  electrical  and  mechanical  (e.g.,  pad  spacing)  points  of  view.  Hence,  if 
a  downscaling  is  allowed  (by  giving  MIN-LAMBDA  <  LAMBDA)  then  the  given  pads  must  be  oversized. 
If  MIN-LAMBDA  and/or  MAX-LAMBDA  are  not  specified,  they  assume  the  same  value  as  LAMBDA. 

The  fabrication  of  the  project  will  be  performed  only  if:  there  is  a  valid  CIF  file  (which  could  be 
submitted  either  within  this  request  or  by  a  previous  SUBMIT  request);  the  value  of  lambda  for  the 
project  is  specified;  and  all  the  required  parameters  are  provided. 

C.6.  The  UPDATE  Request 

This  request  asks  MOSIS  to  change  one  or  more  parameters  pertaining  to  a  project. 

The  project  ID  and  password  (P-PASSWORD)  are  mandatory  for  this  request.  The  optional 
parameters  for  this  request  are  the  name  of  the  project  (P-NAME),  the  description,  the  net-address, 
the  phone  number  of  the  designer(s),  the  value  of  lambda,  MIN-LAMBDA,  MAX-LAMBDA,  and  the 
number  of  pads.  In  addition,  as  in  other  requests,  comments  may  be  added  and  manual  attention, 
special  handling,  and  bonding  instructions  may  be  requested. 


C.7.  The  DELETE-CIF  Request 

This  is  a  request  to  delete  a  CIF  file  which  has  previously  been  submitted  and  accepted.  It  may  be 
issued  at  any  time  after  the  CIF  file  is  accepted,  but  not  after  fabrication  is  requested. 

MOSIS  will  respond  to  this  request  with  a  message  notifying  that  the  CIF  file  has  been  deleted.  When 
the  CIF  file  is  deleted  the  size  parameter  of  the  project  is  set  to  zero,  but  no  other  parameter  is 
changed.  Hence,  any  submission  of  a  CIF  file  must  always  include  the  size.  The  project  ID  and 
password  (P-PASSWORD)  are  mandatory  for  this  request.  In  addition,  sis  in  most  requests,  comments 
may  be  added  and  manual  attention,  special  handling,  and  bonding  instructions  may  be  requested. 

C.8.  The  CANCEL-FABRICATE  Request 

This  request  will  withdraw  a  previous  request  to  fabricate  a  project.  It  also  implies  the  deletion  of  the 
CIF  file.  It  does  not  cause  the  project  itself  to  be  withdrawn  from  MOSIS.  This  request  should  be  used 
for  correcting  and  resubmitting  CIF.  CIF  corrections  should  always  be  made  as  soon  as  possible. 

If  fatal  design  errors  are  found  by  the  designer,  MOSIS  appreciates  a  cancellation  request  as  soon  as 
possible,  even  if  fabrication  is  already  in  progress,  in  order  to  avoid  the  expensive  bonding  of  projects 
which  are  known  to  have  problems.  If  a  user  submits  this  request  when  fabrication  is  already  in 
progress,  MOSIS  will  reply  with  a  message  notifying  whether  the  fabrication  is  actually  cancelled.  If 
the  fabrication  is  actually  cancelled  and  the  user  wishes  to  fabricate  a  new  version  of  the  project,  he 
must  either  submit  a  new  CIF  file  for  future  fabrication  or  issue  a  new  NEW-PROJECT  request. 

The  project  ID  and  password  (P-PASSWORD)  are  mandatory  for  this  request.  Again,  comments  may 
be  added  and  manual  attention,  special  handling,  and  bonding  instructions  may  be  requested. 

C.9.  The  CANCEL-PROJECT  Request 

This  request  asks  MOSIS  to  cancel  the  project  (i.e.,  to  delete  the  design  and  all  other  data  concerning 
the  project)  from  the  MOSIS  system.  The  user  has  then  completely  withdrawn  the  project  from 
MOSIS.  MOSIS  appreciates  cancellation  requests  ASAP,  even  if  fabrication  is  already  in  progress,  in 
order  to  avoid  the  expensive  bonding  of  projects  which  are  known  to  have  problems. 

If  a  user  submits  this  request  when  fabrication  is  already  in  progress,  MOSIS  will  respond  with  a 
message  describing  any  action  taken  on  the  request. 

The  project  ID  and  password  (P-PASSWORD)  are  mandatory  for  this  request.  In  addition,  comments 


C.10.  The  STATUS  Request 

This  request  asks  MOSIS  to  describe  the  status  of  a  project.  MOSIS  will  respond  with  estimated  dates 
for  fabrication  and  distribution  of  the  project. 

The  project  ID  is  mandatory  for  this  request.  Again,  comments  may  be  added  and  manual  attention, 
special  handling,  and  bonding  instructions  may  be  requested. 

C.1 1 .  The  REPORT  Request 

This  request  is  used  to  supply  feedback  on  previously  fabricated  devices  to  the  MOSIS  project. 
Reports  help  MOSIS  evaluate  fabrication  vendors  and  their  processes. 

The  project  ID  and  password  (P-PASSWORD)  are  mandatory  for  this  request;  however,  the  project 
name  (P-NAME)  and/or  Fab-ID  should  be  added.  These  parameters  are  to  be  followed  by  the 
parameter  REPORT.  The  report  may  use  as  many  lines  of  text  as  needed.  The  inclusion  of  the 
Fab-ID  is  especially  useful  to  MOSIS  in  the  event  that  the  project  is  fabricated  on  more  than  one  run. 

Several  reports  on  various  projects  may  be  submitted  in  one  message.  Several  reports  on  one  project 
may  be  submitted  in  one  message. 

C.1 2.  The  ATTENTION  Request 

This  request  asks  MOSIS  to  bring  something  to  the  attention  of  the  MOSIS  team.  The  request  may 
contain  arbitrary  text;  no  parameters  (not  even  COMMENT)  are  recognized.  MOSIS  will  respond  with 
an  acknowledgment  and  will  forward  the  entire  request  to  the  MOSIS  team  for  further  consideration. 

C.1 3.  The  END  Request 

This  request  marks  the  end  of  requests  in  a  message.  All  text  following  this  request  is  ignored  by 
MOSIS. 

(D)  Requests  and  Parameters 

A  MOSIS  service  request  is  a  network  message  in  a  special  format.  Each  message  to  MOSIS  may 
contain  several  REQUESTS,  each  of  which  may  contain  several  parameters  that  are  arguments  for  the 
requests.  To  begin  a  request,  one  includes  in  a  message  a  line  with  the  keyword  "REQUEST:" 
followed  by  the  name  of  the  request. 

Following  the  request  line  is  some  number  (depending  on  the  request)  of  parameter  specification 
lines.  Typically,  one  parameter  is  specified  per  line.  Each  parameter  specification  reads: 


I 


<par-name>:  <par-spec>  where  <par-name>:  is  the  name  of  some  parameter,  and  <par-spec>  the 
specification  of  the  parameter.  Exceptions  to  this  are  detailed  in  the  individual  request  and  parameter 
descriptions. 

Following  the  parameter  spi  cifications  is  either  another  request  or  the  "END"  request,  which  signals 
the  end  of  all  the  requests  contained  in  this  message.  Any  text  in  the  message  following  this  line  is 
ignored  by  MOSIS.  All  requests  (except  the  "END"  request)  will  be  answered  by  MOSIS — please  wait 
for  a  reply  to  one  request  before  sending  another  request  for  the  same  project.  Replies  will  detail 
what  actions  MOSIS  has  taken  on  the  request  and,  if  necessary,  the  reasons  for  those  actions. 

All  request  and  parameter  names  may  be  abbreviated,  as  long  as  no  ambiguities  are  caused. 

D.1 .  Possible  Requests 

The  MOSIS  requests  are: 

INFORMATION  Request  for  information  on  MOSIS  procedures. 

LIBRARY  Request  for  information  from  MOSIS  library. 

NEW-PROJECT  First  message  from  user  to  MOSIS  regarding  new  project. 

SUBMIT  Submittal  of  CIF  file  for  CIF-check  only. 

FABRICATE  Request  to  fabricate  project. 

UPDATE  Modification  of  project  parameters. 

DELETE-CIF  Deletion  of  last  CIF  file  submitted  for  project. 

CANCEL-FABRICATE  Request  to  cancel  previously  requested  fabrication  of  project. 
CANCEL-PROJECT  Total  withdrawal  of  project. 

STATUS  Request  for  status  of  project. 

REPORT  User  report  on  performance  of  fabricated  devices. 

ATTENTION  Request  to  bring  to  the  attention  of  the  MOSIS  staff  some  special  message  or 

project  requirement. 


END 


Termination  of  all  requests  in  message. 


D.2.  Parameters  for  the  Requests 

The  parameters  and  their  format  are  (alphabetically): 

ACCOUNT  <1  line>  Identification  of  account  to  be  charged  for  project. 

AFFILIATION  <1  line>  Name  of  designers'  affiliated  organization. 

ATTENTION  <Any  number  of  lines  to  next  parameter  or  end  of  message>  Requests  to  bring  to 
the  attention  of  the  MOSIS  staff  some  special  message  or  project  requirement. 
May  be  abbreviated  as  ATTN. 

Note:  ATTENTION  may  be  either  a  REQUEST  or  a  parameter  of  other  requests.) 

BOND-SAME-AS  <1  line>  Specifies  need  for  bonding  to  duplicate  that  of  an  earlier  project.  User 
may  supply  either  Project  ID  or  Fab-ID  of  project  to  be  duplicated. 

BYTE-LIMIT  <Number>  Limits  number  of  bytes  in  body  of  message(s)  that  MOSIS  sends  back 
to  users  requesting  information  or  library  file(s). 

CIF  <any  number  of  lines  following,  to  end  of  message  or  to  next  line  starting  with 

"REQUEST:  ">  The  project  design. 

Note:  The  keyword  "CIF."  has  no  arguments  but  is  followed  on  the  next  and 
subsequent  lines  by  the  project  design  itself. 

Note  also  that  the  CIF  design  must  be  the  last  item  in  the  request.  Lines  following 
the  CIF  design,  but  which  do  not  begin  with  "REQUEST:",  will  be  considered  part 
of  the  CIF  design  (e.g.,  within  the  SUBMIT  request,  if  "ATTENTION:  <text>"  is 
placed  following  the  CIF  text,  it  will  be  considered  part  of  the  CIF  so  that  the 
request  will  not  be  manually  processed). 

It  is  highly  recommended  that  the  CIF  be  explicitly  terminated  by  another  request 
(e.g.,  REQUEST:  END)  rather  than  implicitely  by  the  end  of  the  message. 

CIF-CHECKSUM  Set  of  numbers  computed  for  CIF  file  or  fragment  to  help  determine  integrity  of 
received  file  or  fragment.  See  Section  G. 

CIF-FRAGMENT  Fragment  of  CIF  file  for  project.  See  Section  F.2. 

CIF-FTP-PATH  List  of  parameters  needed  to  FTP  CIF  file  to  MOSIS.  Alternative  to  CIF  parameter. 
See  Section  G. 

COMMENT  <Any  number  of  lines  to  next  parameter  specif ication>  Text  totally  ignored  by 

MOSIS,  to  be  used  by  designer  for  any  purpose. 

DESCRIPTION  <Any  number  of  lines>  Relatively  long  description  of  project. 
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id 


O-NAME 


D-PASSWORD 


LAMBDA 


LINE-LIMIT 


MAX-LAMBDA 


<1  line>  Name  of  MOSIS  user  submitting  the  project. 

<1  line>  Password  given  to  this  user  (D-NAME)  to  authenticate  new  project 
requests  sent  to  MOSIS. 

<Number>  Unique  identification  of  project  assigned  by  MOSIS. 

<Number>  Value  of  lambda  that  applies  to  this  CIF  file.  Microns  assumed,  but  may 
be  specified  in  mils,  e.g.,  ".08  mils".  Lambda  is  one  half  the  minimum  feature  size, 
and  it  must  be  provided  even  if  the  design  system  does  not  use  lambda  internally. 

<Number>  Limits  number  of  lines  in  body  of  message(s)  that  MOSIS  sends  back  to 
users  requesting  information  or  library  file(s). 

<Number>  Maximum  value  of  lambda  to  which  design  may  be  scaled,  in  microns 
(or  mils  if  so  stated;  see  LAMBDA).  If  not  specified,  then 
MAX-LAMBDA  »  LAMBDA  is  used  and  no  scaling  up  of  project  will  take  place. 
Scaling  applies  only  to  custom  frame  projects. 


MAILING  ADDRESS 


MIN-LAMBDA 


<Any  number  of  lines>  Address  for  MOSIS  to  send  packaged  parts  and 
correspondence.  Should  be  in  EXACT  form  for  shipping  label  and  should 
particularly  include  the  actual  designer’s  name  and  street  address  of  organization 
(including  MAIL-STOP,  etc.).  DO  NOT  USE  Post  Office  box  numbers;  the 
overnight  courier  will  not  accept  them. 

Warning:  Do  not  include  ATTN:  or  ATTENTION:  at  the  beginning  of  a  line  in 
MAILING-ADDRESS  or  MOSIS  will  interpret  it  as  ATTENTION  parameter. 

<Number>  Minimum  value  of  lambda  to  which  design  may  be  scaled,  in  microns 
(or  mils  if  so  stated;  see  LAMBDA),  If  not  specified  then  MIN-LAMBDA  =  LAMBDA 
is  used  and  no  scaling  down  of  project  will  take  place.  Scaling  applies  only  to 
custom  frame  projects. 


NET-ADDRESS  <username>@<sitename>  {,<username>@<sitename>}*,  1  line. 

Note:  MOSIS  will  send  replies  to  requests  to  above  net  addresses.  It  is  very 
important  that  the  address(es)  be  kept  current  throughout  the  lifetime  of  the 
project.  See  the  Section  I  for  information  regarding  Internet  and  Telemail 
addresses. 


PADS 


PHONE 


<Number>  Number  of  pads  to  be  bonded  for  project.  If  this  parameter  is  left 
unspecified,  all  boxes  on  the  glass  layer  will  be  bonded.  Pads  value  of  0  will 
produce  an  unbonded,  unpackaged  chip.  This  parameter  should  not  be  supplied 
for  a  standard  frame  project. 

<1  line>  Telephone  number(s)  where  user(s)  can  be  reached. 


.w 


P-NAME 


<1  line>  Short  name  for  project,  e.g.,  ADDER  or  SHIFTER. 


P-PASSWORD  <1  line>  Arbitrary  password  assigned  to  project  by  user  in  NEW-PROJECT 
request. 

REPORT  <Any  number  of  lines,  however,  this  parameter  must  be  the  last  one  before  next 

"REQUEST:"  or  end  of  message>  User  report  to  MOSIS  on  performance  of 
fabricated  project. 

SIZE  <X  dimension>  x  <Y  dimension>  Size  of  project  in  microns  (or  in  mils  if  so  stated; 

e.g.,  “300  x  500  mils").  Required  before  CIF  check  for  custom  frame  projects 
only.  See  Section  H.  1.2. 

SPECIAL-HANDLING 

<Any  number  of  lines>  Specifies  special  size  and  bonding  requests. 

STD-FRAME  <1  line>  Name  of  standard  pad  frame,  i.e.,  one  of  several  bonding  pad  placements 
for  which  MOSIS  is  able  to  offer  automatic  wire-bonding. 

TECHNOLOGY  <1  line>  Technology  required  for  project. 

TOPIC  <1  line>  Name  of  information  topic  desired.  Note:  Requesting  TOPIC:  TOPICS  will 

retrieve  a  list  of  all  available  information  topics. 


D.3.  Relationship  of  Parameters  to  Requests 

Each  project  must  be  initiated  by  the  NEW-PROJECT  request.  The  FABRICATE  message  must  be 
issued  in  order  to  fabricate  a  project.  These  are  the  only  mandatory  messages.  All  other  messages 
are  optional.  The  following  table  shows  the  relationships  between  the  requests  and  the  parameters. 
Note  that  parameters  for  the  messages  are  either  mandatory  or  optional. 


REQUEST 

MANDATORY 

OPTIONAL 

INFORMATION 

TOPIC 

COMMENT 

ATTENTION 

BYTE-LIMIT 

LINE-LIMIT 

LIBRARY 

TOPIC 

COMMENT 

ATTENTION 

BYTE-LIMIT 

LINE-LIMIT 

NEW-PROJECT 

D-NAME(+  *)  TECHNOLOGY 

AFFILIATION  +  *)  LAMBDA 

ACCOUNT(  +  *)  MIN-LAMBDA 

D-PASSWORD(  +  *)  MAX-LAMBDA 

NET-ADDRESS  SIZE 

MAILING-ADDRESSC)  PADS 

P-NAME  COMMENT 

P-PASSWORD(’)  ATTENTION 

DESCRIPTION  PHONE 

SPECIAL-HANDLING 

BOND-SAME-AS 

STD-FRAME 

Note:  The  parameters  marked  "  +  "  are  those  which  must  match  exactly  the  values  in  the  access 
tables  of  MOSIS,  which  are  not  communicated  via  the  rvet  messages  described  here.  The  parameters 
marked  are  those  which  cannot  be  changed  through  messages  during  the  lifetime  of  the  project. 


request 


OPTIONAL 


SUBMIT  ID  P-NAME 

P-PASSWORD  DESCRIPTION 

NET-ADDRESS 

PHONE 

TECHNOLOGY 

LAMBDA 

MIN-LAMBDA 

MAX-LAMBDA 

SIZE 

PADS 

CIF 

CIF-FRAGMENT 

CIF-FTP-PATH 

CIF-CHECKSUM 

COMMENT 

ATTENTION 

SPECIAL-HANDLING 

BOND-SAME-AS 

STD-FRAME 

FABRICATE  ID  P-NAME 

P-PASSWORD  DESCRIPTION 

NET-ADDRESS 
PHONE 

TECHNOLOGY 

LAMBDA 

MIN-LAMBDA 

MAX-LAMBDA 

SIZE 

CIF 

CIF-FRAGMENT 

CIF-FTP-PATH 

PADS 

CIF-CHECKSUM 

COMMENT 

ATTENTION 

SPECIAL-HANDLING 

BOND-SAME-AS 

STD-FRAME 


Note:  Fabrication  cannot  be  performed  unless  LAMBDA,  TECHNOLOGY,  CIF,  and  either  SIZE 
STD-FRAME  are  already  specified.  The  same  parameters  are  also  required  for  CIF-CHECK. 


MANDATORY 


UPDATE 


ID 

P-PASSWORD 


P-NAME 

DESCRIPTION 

NET-ADDRESS 

PHONE 

LAMBDA 

MIN-LAMBDA 

MAX-LAMBDA 

PADS 

COMMENT 

ATTENTION 

SPECIAL-HANDLING 

BOND-SAME-AS 

STD-FRAME 


DELETE-CIF  ID 

P-PASSWORD 


COMMENT 

ATTENTION 


CANCEL-FABRICATE  ID 

P-PASSWORD 


COMMENT 

ATTENTION 


CANCEL-PROJECT  ID 

P-PASSWORD 


COMMENT 

ATTENTION 


STATUS 


ID  COMMENT 

P-PASSWORD  ATTENTION 


REPORT 


ID 

COMMENT 

P-PASSWORD 

ATTENTION 

P-NAME 

FAB-ID 

ATTENTION 


END 


ID 

P-PASSWORD 


«  The  ID  and  the  password  of 
« the  project  must  be  included 
«  only  in  project-specific 
«  ATTENTION  requests. 


If  any  of  the  mandatory  parameters  are  not  included,  the  entire  request  is  rejected.  When  a  parameter 
is  given  to  MOSIS,  it  replaces  any  previous  value  of  it.  This  does  not  apply  to  the  D-NAME, 
AFFILIATION,  ACCOUNT,  D-  PASSWORD,  P-PASSWORD,  and  the  ID. 


(E)  More  about  MOSIS  Messages 


All  portions  of  requests  are  case-independent.  No  control  codes  other  than  <CR>,  <LF>,  <TAB>,  or  tL 
should  be  used.  No  line  should  begin  with  "XXX:"  unless  "XXX"  is  a  keyword  as  described  above 
(i.e.,  a  "REQUEST”  or  a  parameter).  It  is  recommended  that  the  request  messages  include  in  the 
SUBJECT  field  the  type  of  request  and  the  name  of  the  project;  for  example:  "Subject:  SUBMIT 
ADDER". 

With  one  exception,  MOSIS  will  send  all  responses  concerning  a  project  to  the  net  address(es) 
specified  for  the  project  in  the  NEW-PROJECT  request  (or  an  updated  address(es)  sent  to  MOSIS  by 
the  user  at  a  later  date).  The  exception  occurs  when  there  is  any  problem  with  the  NET-ADDRESS 
parameter  (e  g.,  it  is  omitted)  or  when  an  ID  given  by  the  user  is  not  valid  (e.g.,  does  not  exist  or  is  not 
accompanied  by  the  proper  P-PASSWORD).  In  this  case  MOSIS  directs  the  responses  to  the 
SENDER  of  the  request.  The  SENDER  is  determined  from  the  first  parameter  in  the  following  list  that 
also  appears  in  the  message  before  the  first  MOSIS  request:  REPLY-TO,  SENDER,  FROM. 

(F)  Submittal  Procedures 

The  standard  procedure  for  submitting  projects  to  MOSIS  for  fabrication  consists  of  three  steps: 

1 .  Sending  the  NEW-PROJECT  request  and  receiving  a  project  ID  from  MOSIS. 

2.  Submitting  the  CIF  file  for  the  project  using  the  SUBMIT  request  containing  the  MOSIS  ID. 

3.  Requesting  the  fabrication  of  the  already  submitted  project  using  the  FABRICATE 
request  containing  (again)  the  MOSIS  ID. 

These  requests  can  only  be  issued  after  the  designer  has  been  authorized  as  a  MOSIS  user.  It  is 
possible  to  combine  steps  (2)  and  (3)  above  or  even  (1),  (2),  and  (3)  above  into  a  single  step. 
However,  in  certain  situations  this  procedure  cannot  be  used.  The  following  are  descriptions  of 
1-step  and  N-step  submittal  procedures. 
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F.1 .  The  1-step  Submittal  Procedure 


This  procedure  is  useful  to  users  who  need  to  expedite  the  submittal  procedure.  The  1-step 
procedure  consists  of  a  single  message  which  contains  the  NEW-PROJECT  request  followed  by  the 
FABRICATE  request.  It  uses  an  asterisk  for  the  project  ID.  Only  the  requests  contained  in  this 
message  may  use  the  as  the  ID  for  this  project.  All  further  requests  regarding  this  project  must 
include  the  real  ID  as  assigned  by  MOSIS. 


1 


The  following  is  an  example  of  the  1-step  submittal: 


•  e 

Request: 

NEW-PROJECT 

D-name : 

POOH 

Affiliation: 

NAVY 

Account: 

VLSI 

D-password: 

honey 

Net-Address: 

PoohBNavy 

Mall  Ing-Addr: 

Or.  W.  T.  Pooh 

US  Navy 

Anapol Is .  Md.  23456 

P-name: 

MULTIPLY  16x20 

P-Password: 

TIMBAK 

Description: 

This  Is  a  super  fast  16x20  bit 

multiplier  for  l's  compliment 

arithmetics,  using  2-bit  at  a 

time. . . 

Technology: 

NMOS/MC 

Lambda: 

2.5 

Pads: 

39 

Request: 

FABRICATE 

ID: 

P-Password: 

TIMBAK 

SIZE: 

1850  x  3200 

CIF : 

(LAP281B  ---  VFFT.CIF); 

(symbol  VFFT); 

DS  1  250  10; 

L  NO; 

W  20  960,-50  960,100; 

B  60  500  1030,80; 

Request: 

E 

END 

•  • 

— 

•  • 

a 


F.2.  The  N-step  Submittal  Procedure 

Some  MOSIS  users’  mail  systems  do  not  allow  them  to  send  long  messages.  This  causes  difficulties 
in  the  submission  of  large  CIF  files,  but  not  in  sending  other  messages. 

These  users  may  use  the  following  procedure: 

1.  Issue  a  NEW-PROJECT  request  and  wait  for  the  MOSIS  project  ID  to  be  assigned  by 
MOSIS. 

2.  Divide  the  original  CIF  file  into  N  small  fragments,  such  that  each  fragment  is  small 
enough  to  be  handled  in  a  single  message.  Fragment  the  CIF  on  both  line  and  command 
boundaries. 

3.  Send  N  messages  to  MOSIS,  each  with  a  fragment,  using  the  SUBMIT  request  and  the 
CIF-FRAGMENT  parameter  as  described  below. 

4.  After  all  of  the  fragments  are  accepted  by  MOSIS  and  the  CIF  is  found  valid,  issue  the 
FABRICATE  request. 

Each  SUBMIT  request  should  include  the  same  parameters  as  in  the  standard  procedure  except  that, 
instead  of  the  parameter  CIF,  the  parameter  CIF-FRAGMENT  should  be  used.  The  line  with  this 
parameter  should  look  like  "CIF-FRAGMENT:  K/N",  where  N  is  the  total  number  of  fragments  in  the 
CIF  file  for  this  project  and  K  is  the  number  of  this  fragment.  The  CIF  commands  should  start  on  the 
next  line  after  the  CIF-FRAGMENT. 

The  acceptance  of  each  of  the  fragments  will  be  acknowledged.  Only  the  acceptance  of  the  last  one 
(with  N/N)  will  trigger  the  automatic  CIF  check.  Only  after  submitting  the  last  fragment  may  the 
FABRICATE  request  be  issued. 

The  DELETE-CIF  request  may  be  used  at  any  time  to  terminate  the  submittal  of  CIF  fragments.  This  is 
useful  when  sudden  revisions  to  a  project  are  necessary. 

AN  IMPORTANT  NOTE  ON  SUBMITTING  CIF: 

Any  submission  of  CIF  is  terminated  either  explicitly,  by  the  next  request  (typically: 
"REQUEST:  END"),  or  implicitly,  when  the  end  of  the  message  is  reached.  The  latter  termination 

typically  results  in  the  message  trailer  (e.g.,  " . "  of  SNDMSG)  being  appended  to  the  end  of  the 

CIF.  This  addition  is  not  harmful  after  the  CIF  "E"  command  which  terminates  the  CIF  file;  however, 
such  trailer  may  be  harmful  at  the  end  of  CIF-FRAGMENTS  which  may  be  in  arbitrary  positions  in  the 
middle  of  a  CIF  file.  Therefore,  all  CIF  submissions  (especially  when  using  CIF-FRAGMENT)  should 
be  explicitly  terminated  by  the  next  request,  i.e.,  "REQUEST:  END”. 


so 


(G)  CIF  Information 

G.1 .  The  CIF-CHECKSUM  Option  for  SUBMIT  and  FABRICATE 

The  CIF-CHECKSUM  option  is  intended  to  deal  with  situations  similar  to  those  in  which  CIF  files  are 
created  on  one  computing  system  (e  g.,  UNIX),  then  transferred  (e.g.,  via  a  local  net  or  a  mag-tape)  to 
another  system  (e.g.,  TOPS-20)  for  transmission  to  MOSIS  in  network  messages.  In  these  situations 
the  CIF-CHECKSUM  option  should  be  computed  by  the  originating  system  (UNIX,  in  this  example)  on 
the  entire  CIF  file  (or  each  CIF  fragment,  if  the  file  must  be  fragmented  for  submittal  to  MOSIS). 

In  such  situations  the  CIF  files  may  undergo  several  trivial  modifications,  such  as  replacing  EOLs  or 
<CR>s  by  <CRXLF>s,  addition/deletion  of  nulls  and  of  trailing  spaces,  conversion  of  TABc  into 
SPACEs  and  addition  of  spaces/<CR>s  at  either  end  of  the  file.  The  CIF-Checksum  is  expected  to  be 
insensitive  to  these  trivial  transformations. 

The  CIF-CHECKSUM  refers  to  the  CIF  in  the  same  message,  whether  it  is  an  entire  CIF  file,  a  single 
CIF-FRAGMENT,  or  a  CIF-FTP-PATH. 

The  CIF  checksum  option  may  be  used  in  a  SUBMIT  or  FABRICATE  request,  whenever  the  sender  of 
CIF  files  or  fragments  desires.  It  is  never  mandatory.  If  the  checksum  is  given,  MOSIS  will  compute 
one  for  the  CIF  file  or  fragment  and  compare  the  two.  A  mismatch  between  a  computed  and  a  given 
checksum  is  reported  to  the  sender,  and  the  CIF  file  or  fragment  is  rejected  as  invalid.  If  a  CIF 
fragment  is  rejected  as  invalid,  the  CIF  sent  so  far  is  still  intact;  only  the  rejected  fragment  needs  to  be 
sent  again. 

G.2.  Computation  of  the  CIF-CHECKSUM 

The  following  is  the  definition  of  this  CIF-CHECKSUM. 

•  The  checksum  is  defined  only  for  files  consisting  of  ASCII  characters.  All  bytes  are 
treated  as  7-bit  ASCII  codes. 

•  Null  characters  (ASCII-O)  are  ignored. 

•  All  characters  (bytes)  are  assigned  values  which  are  their  7-bit  ASCII  codes  (e.g.,  their 
ASCII  code  modulo  128)  if  these  values  are  above  32-decimal  (40-octal),  the  SPACE 
byte. 

•  If  this. value  is  not  above  32,  then  the  byte  is  considered  to  be  a  SEPARATOR.  All 
sequences  of  consecutive  separators  are  given  one  value  of  32  and  counted  as  a  single 
character  regardless  of  their  length. 

•  The  checksum  (CKSUM)  is  the  sum  of  the  values  (as  defined  above)  of  all  the  bytes  in  the 
file.  It  is  computed  as  if  there  are  separators  at  both  the  beginning  and  end  of  the  file. 


•  The  character  count  (NCHAR)  is  the  number  of  non-separator  characters  plus  the 
number  of  separator-sequences  (including  the  implied  ones  at  the  beginning  and  end  of 
the  file). 

•  The  checksum  field  is  a  string  of  decimal  digits  expressing  the  CKSUM  (as  defined  above) 
and  NCHAR,  separated  by  space(s).  These  numbers  must  always  be  positive. 

•  Leading  and  trailing  spaces,  and  leading  zeros,  are  allowed  to  be  in  this  field,  and  are 
ignored  for  comparison  purposes. 


The  actual  computation  of  the  CKSUM  is  as  follows: 

1.  •  Set  PREVICHRISEP  to  TRUE. 

*  Assign  the  value  32(decimal)  to  CKSUM, 

*  Assign  the  value  1  to  NCHAR. 

2.  For  each  byte  from  the  file: 

IF  it  is  a  null  then  ignore  it,  ELSE 
Assign  its  7-bit-ASCII  value  to  THISIBYTE, 
IF  THIS!BYTE>32 
THEN 

*  Add  THISIBYTE  to  CKSUM, 

*  Add  1  to  NCHAR, 

•  Set  PREV1CHRISEP  to  FALSE. 

ELSE 

•  IF  PREVICHRISEP 
THEN  ignore  it, 

ELSE 

•  Add  32  to  CKSUM, 

•  Add  1  to  NCHAR, 

•  Set  PREVICHRISEP  to  TRUE. 

3.  IF  PREVICHRISEP  »  FALSE 
THEN 

•  Add  32  to  CKSUM, 

•  Add  1  to  NCHAR. 

4.  Output  the  value  of  CKSUM  and  NCHAR. 


Programs  which  compute  the  checksum  values  are  available  through  MOSIS  via  the  INFORMATION 
request  with  the  following  TOPIC  values: 

TOPIC:  Program  source  language 

CKSUM  1  .MAC  TOPS-20  MACRO  assembler 


CKSUM1.C 


TOPS-20  C  compiler  (readily  modified  for  other  operating  systems) 
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G.3.  The  CIF-FTP-PATH  Option 

MOSIS  can  accept  CIF  for  projects  by  using  FTP  to  retrieve  them.  The  FTP-path  for  the  CIF  is 
specified  by  a  one-line  parameter  of  the  form: 

CIF-FTP-PATH:  /hostname/username/password/account/filename 

where  the  character  "/"  may  be  replaced  by  any  printing  character  that  is  to  be  used  to  delimit  the 
parameter  fields,  and  where 

hostname  is  the  name  of  an  Internet  host  known  to  ISI, 

username  is  the  name  of  a  user  on  that  host  who  can  login  via  FTP  (or  if  no  user  name  is 

needed,  this  field  may  be  left  empty), 

password  is  the  literal  password  needed  to  do  the  FTP  login  (this  field  may  be  left  empty  if 

not  required), 

account  is  the  account  under  which  the  user  needs  to  login  via  FTP  (this  field  may  be  left 

empty  if  not  required), 

filename  is  the  name  of  the  file  containing  the  CIF  text. 

This  line  may  be  included  in  place  of  the  CIF:  or  CIF-FRAGMENT:  line  of  a  SUBMIT  or  FABRICATE 
request.  The  following  is  an  example  of  the  use  of  this  line  in  a  FABRICATE  request: 


REQUEST: 

ID: 

P-P: 

CIF-FTP-PATH: 

REQUEST: 


FABRICATE 

67890 

SAY-WHAT? 

IISIFIVLSI-TESTITESTHTEST.CIF 

END 


NOTE:  The  user  chose  the  field  delimiter  to  be  the  character  "1”.  No  FTP  account  parameter  is,  but 
the  delimiters  for  the  account  field  are  retained. 

MOSIS  will  make  periodic  transfer  attempts.  The  desired  file  must  be  unprotected.  MOSIS  will  notify 
the  user  either  when  the  transfer  is  successful  (this  message  will  include  the  CIF-CHECKSUM 
computed  for  the  file),  or  if  the  transfer  attempts  fail. 

If  a  CIF-checksum  is  provided  with  this  CIF-FTP-Path,  then  it  is  stored  for  comparison  by  MOSIS  after 
the  CIF  is  retrieved.  If  FTP  retrieval  of  CIF-fragments  is  necessary,  the  user  may  obtain  instructions 
from  MOSIS  by  sending  an  ATTENTION  request.  The  FTP  retrieval  service  is  available  only  to  hosts 
implementing  DARPA's  IP/TCP/FTP,  and  is  not  available  through  Telemail. 


(H)  Project  Requirements  and  Special  Requests 
H.1 .  Packaging  and  Bonding 

MOSIS  uses  both  28-pin,  40-pin,  and  64-pin  DIPs,  and  84-pin  grid  arrays.  Packaging  in  64-pin  and 
84-pin  packages  may  take  longer  than  packaging  in  28-pin  and  40-pin  packages.  A  project  may  use 
either  a  MOSIS  standard  project  frame  (as  described  in  the  Section  H.1. 2)  or  a  custom  frame 
designed  by  the  user  (see  Section  H.1. 3).  Packaging  in  custom  frames  may  take  longer  than 
packaging  in  standard  frames. 

The  use  of  standard  library  bonding  pads  is  highly  recommended.  Instructors  should  prevent  creative 
bonding  by  students. 

H.1 .1 .  Standard  project  frames 

The  MOSIS  service  offers  standard  frames  as  an  alternative  to  custom  project  frames  where  every 
project  pad  layout  is  unique.  A  standard  project  frame  is  a  rectangular  area  of  a  fixed  size  and  with  a 
fixed  set  of  bonding  pad  locations  around  the  periphery  of  the  rectangle.  The  circuitry  in  the 
remainder  of  the  frame,  the  routing  of  pad  connections,  and  the  choice  of  pad  types  at  each  of  the 
fixed  locations  are  up  to  the  user. 

The  use  of  standard  frames  has  numerous  advantages  over  custom  frames  to  both  the  MOSIS  service 
and  the  user  community: 

1 .  The  bonding  of  projects  in  standard  frames  is  always  the  same  for  a  given  frame; 
therefore,  packaging  is  both  faster  and  more  reliable. 

2.  Designers  using  standard  frames  determine  their  own  package  pin-out. 

3.  The  future  MOSIS  pad  routing  service  will  support  automatic  pad  routing  to  the  standard 
frame  chosen. 

4.  The  future  MOSIS  functional  testing  service  will  provide  probe  cards  for  the  standard 
frames;  projects  in  custom  frames  will  have  to  create  their  own  private  probe  cards. 


The  Frames 

Standard  frames  are  available  in  six  sizes  and  four  different  pad  counts,  for  a  total  of  eleven  standard 
frames  as  listed  in  the  table  below.  The  matrix  shows  the  official  "name"  assigned  to  each  frame 
offered.  Each  frame  size  represents  the  total  area  available  to  the  user  for  project  geometry;  all  scribe 
lanes,  markings,  and  other  manufacturing  and  processing  details  are  added  by  MOSIS  outside  this 
frame. 


Frame 

- . --Package - 

(microns) 

28 

40 

64 

84 

7900 

x  9200 

-- 

— 

64P79X92 

84P79X92 

6900 

x  6800 

— 

40P69X68 

64P69X68 

84P69X68 

4600 

x  6800 

-- 

40P46X68 

64P46X68 

— 

4600 

x  3400 

26P46X34 

40P46X34 

— 

— 

2300 

x  3400 

28P23X34 

— 

-- 

-- 

1900 

x  2558 

— 

ParcBasic 

-- 

-- 

The  28-and  40-pin  packages  are  both  0.6"  wide  DIPs;  the  64-pin  package  is  a  0.9”  DIP;  the  84-pin 
package  is  a  pin  grid  array. 

The  pad  layout  of  each  standard  frame,  other  than  "ParcBasic",  has  one-fourth  of  the  pads  evenly 

spaced  along  each  side.  "ParcBasic"1  is  taken  directly  from  the  Basic  Design  Frame  that  was 

conceived  at  Xerox  PARC  (see  "The  Design  of  a  Basic  Design  Frame"  by  Alan  Paeth,  available  from 

XeroxPARC);  this  layout  corresponds  to  the  design  frame  at  lambda  equals  2.0  microns.  The 

following  table  characterizes  the  pad  layouts  in  terms  of  three  parameters;  the  units  are  microns. 

Pad-to-Edge  the  distance  from  the  center  of  each  pad  to  the  adjacent  frame  boundary. 

Pad-to-Edge  is  intended  to  be  sufficient  to  accommodate  the  pad  itself  and  a 
ground  bus  around  the  outside;  the  minimum  pad-to-edge  value  is  sufficient  to 
accommodate  MOSIS  standard  library  pads. 

Pad-to-Pad  the  (center  to  center)  distance  between  pads  along  an  edge.  The  minimum  value 
is  256  microns  (for  the  next  round  of  larger  packages,  the  spacing  will  necessarily 
decrease  to  about  200  microns  or  so). 

Pad-to-Corner  the  distance  from  the  center  of  the  first/last  pad  on  an  edge  to  the  corner  of  the 
frame.  Where  there  is  sufficient  room,  a  minimum  corner  spacing  of  750  microns 
is  maintained. 


Viaure  3  shows  three  instances  of  the  ParcBasic  standard  frame. 


The  first  number,  pad-to-edge,  is  the  same  for  all  the  pads  in  a  frame,  but  the  other  two  are  set 
separately  for  each  pair  of  sides.  The  described  orientation  has  N(orth)  corresponding  to  the  +  Y 
direction  of  the  Cartesian  coordinate  system  used  in  CIF,  E(ast)  to  the  +  X  direction,  W(est)  to  the  -X 
direction,  and  S(outh)  to  the  -Y  direction. 


Frame 

— 

-N/S - 

— 

■E/W . 

(Name) 

Edge 

Pad 

Corner 

Pad 

Corner 

ParcBasic 

140 

(none ) 

272 

480.174 

28P23X34 

150 

256 

382 

300 

800 

28P46X34 

160 

500 

800 

300 

800 

40P46X34 

150 

300 

950 

256 

548 

40P46X68 

150 

300 

950 

500 

1150 

64P46X68 

ISO 

256 

380 

300 

1150 

40P69X68 

200 

500 

1200 

500 

1150 

64P69X66 

200 

300 

1200 

300 

1150 

84P69X68 

200 

300 

450 

300 

400 

64P79X92 

250 

400 

950 

500 

850 

84P79X92 

250 

300 

950 

375 

850 

These  numbers  are  reflected  in  the  CIF  and  LIST  files  described  below. 

All  the  pads  of  a  standard  frame  project  are  bonded  to  the  package  pads  in  a  fixed  pattern.  ParcBasic 
has  its  sixteen  pads  bonded  into  a  40-  pin  DIP  according  to  the  drawing  in  the  design  paper.  The 
other  DIP  frames  number  pads  beginning  at  #  1 ,  which  is  at,  or  immediately  above,  the  center  of  the 
E(ast)  or  +  X  side,  and  proceeding  counterclockwise  around  the  frame.  The  pin  grid  array  frames 
locate  pad  tt  1  at  the  E(ast)  end  of  the  N(orth)  side  and  proceed  counterclockwise,  terminating  at  the 
N(orth)  end  of  the  E(ast)  side.  The  CIF  files  distributed  by  MOSIS  highlight  pin  it  1 . 

Note  that  MOSIS  will  connect  package  pin  it  1  to  both  the  silicon  substrate  and  project  pad  it  1 .  The 
preceding  statement  does  not  apply  to  CMOS/SOS  projects. 

H.1 .2.  Procedures  for  using  standard  frames 

To  use  a  standard  frame,  the  user  must: 

1.  acquire  from  MOSIS  (or  derive  from  the  table  above)  a  description  of  the  frame(s)  of 
interest; 

2.  integrate  that  description  into  a  design  (i.e.,  put  the  pads  at  the  right  places); 

3.  inform  MOSIS  of  the  standard  frame  that  is  associated  with  a  submitted  project. 
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Standard  frame  descriptions  are  available  from  MOSIS  in  two  forms:  (1)  a  CIF  file  (framenarr.c.CIF) 
that  draws  the  bonding  pads  and  the  frame  outline  and  highlights  pad  #1,  and  (2)  a  text  file 
(framename.LIST)  that  lists  the  bonding  pad  centers,  one  per  line.  These  files  may  be  obtained  via  an 
information  request  to  MOSIS.  For  example,  the  files  for  28P23X34  are  obtained  with  the  following 
request: 

REQUEST:  INFO 

TOPIC:  28P23X34.CIF 

TOPIC:  28P23X34.LIST 

When  submitting  to  MOSIS  a  project  using  a  standard  frame,  the  parameter  "STD-FRAME"  is 
mandatory;  it  may  be  included  in  any  of  the  NEW-PROJECT,  SUBMIT,  FABRICATE,  or  UPDATE 
requests.  The  argument  to  STD-FRAME  is  the  frame  name,  for  example: 

STD-FRAME:  28P23X34 

A  project  in  a  standard  frame  cannot  specify  a  "PADS"  parameter  and  need  not  specify  a  "SIZE" 
parameter.  In  addition,  the  "MIN-LAMBDA"  and  "MAX-LAMBDA"  parameters,  which  are  used  to 

control  the  limits  of  project  scaling,  are  irrelevant  since  standard  frame  projects  are  never  scaled. 

• 

The  MOSIS  CIF  check  for  a  standard  frame  project  will  include  a  check  that  the  project  is  not  larger 
than  the  size  of  the  declared  frame  and  that  ALL  the  pads  of  the  frame  are  indeed  present.  The 
minimum  acceptable  pad  geometry  is  a  90  x  90  micron  glass  cut  box  over  a  100  x  100  micron  metal 
box,  centered  at  the  designated  pad  location.  A  pad  may  be  larger  and/or  off-center,  provided  that  it 
completely  covers  the  minimum  geometry. 

Project  geometry  may  touch  the  frame  boundary;  MOSIS  will  provide  appropriate  separation  between 
adjacent  frames.  However,  when  a  project  is  smaller  than  the  frame  size,  MOSIS  will  figure  the  best  fit 
match  between  the  actual  project  pads  and  those  expected  for  the  frame. 

There  is  no  requirement  anywhere  that  a  project  be  specified  in  terms  of  an  absolute  CIF  origin.  All 
sizes  and  positions  are  relative  to  an  arbitrary  project  origin. 


Following  is  a  sample  CIF  file: 


(  28P23X34.CIF  --  MOSIS  standard  frame  with  28  pads 
(7  per  side)  in  a  2300  x  3400  micron  project  frame. 


Side; 

2300 

3400 

N/S 

E/W 

Pad-to-Pad; 

256 

300 

Pad-to-Corner: 

382 

800 

Pad-to-Edge: 

150 

DS  1  100/1;  (one  minimum  bonding  pad.  center  at  0.0); 
L  NM;  B  100  100  0  0; 

L  NG;  B  90  90  0  0; 

DF; 


DS  3  100/1;  (pad  #1,  marked  for  visibility); 

C  1; 

L  NX;  W  4  -35  10  5  10;  W  4  -35  -10  5  -10; 

W  4  -25  20  -25  -20;  W  4  -5  20  -6  -20; 

W  4  15  30  26  30  25  -30;  W  4  15  -30  35  -30; 
OF; 


OS  2  100/1; 

L  NX;  B  2300  340C  1150  1700;  (The  frame. 

from  0,0  to 


( 

east  side  --  ); 

C 

3 

T 

2150 

1700;  (pin 

c 

1 

T 

2150 

2000;  (pin 

c 

1 

T 

2150 

2300;  (pin 

c 

1 

T 

2150 

2600;  (pin 

( 

north  side  --  ); 

c 

1 

T 

1918 

3250;  (pin 

c 

1 

T 

1662 

3250;  (pin 

c 

1 

T 

1406 

3250;  (pin 

c 

1 

T 

1160 

3250;  (pin 

c 

1 

T 

894 

3250;  (pin 

c 

1 

T 

638 

3250;  (pin 

c 

1 

T 

382 

3250;  (pin 

( 

west  side  --  ); 

c 

1 

T 

150 

2600;  (pin 

c 

1 

T 

150 

2300;  (pin 

c 

1 

T 

150 

2000;  (pin 

c 

1 

T 

150 

1700;  (pin 

c 

1 

T 

150 

1400;  (pin 

c 

1 

T 

150 

1100;  (pin 

c 

1 

T 

150 

800;  (pin 

( 

south  side  --  ); 

c 

1 

T 

382 

150;  (pin 

c 

1 

T 

638 

150;  (pin 

c 

1 

T 

894 

150;  (pin 

c 

1 

T 

1160 

150;  (pin 

c 

1 

T 

1406 

150;  (pin 

c 

1 

T 

1662 

150;  (pin 

c 

1 

T 

1918 

150;  (pin 

( 

east  side  again  -- 

c 

1 

T 

2150 

800;  (pin 

c 

1 

T 

2150 

1100;  (pin 

c 

1 

T 

2150 

1400;  (pin 

#1  --  the  substrate 
#2); 

#3); 

#4); 

#5): 

#6); 

#7); 

#8) ; 

#9); 

#10) ; 

#11): 

#12); 

#13); 

#14); 

#16); 

#16); 

#17); 

#18); 

#19); 

#20); 

#21): 

#22); 

#23); 

#24); 

#26); 

): 

#26); 

#27); 

#28); 


2300,3400); 
connection) ; 
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Following  is  a  sample  LIST  file: 


««  28P23X34 .LIST  »>> 

2150,  1700  --  pin  #1  --  the  substrate  connection 

2150.  2000  --  pin  #2 

2150.  2300  --  pin  03 

2150,  2600  --  pin  04 

1916,  3250  --  pin  #5 

1662.  3250  --  pin  #6 

1406,  3250  --  pin  01 

1150.  3250  --  pin  #8 

894,  3250  —  pin  09 

638.  3250  --  pin  #10 

382.  3250  —  pin  #11 

ISO.  2600  --  pin  #12 

150.  2300  --  pin  #13 

150.  2000  --  pin  #14 

150.  1700  --  pin  #15 

150.  1400  —  pin  #16 

150.  1100  --  pin  #17 

150,  800  --  pin  #18 

382,  160  --  pin  #19 

638,  150  --  pin  #20 

894,  150  --  pin  #21 

1150.  150  —  pin  #22 

1406,  150  --  pin  #23 

1662.  150  --  pin  #24 

1918.  150  --  pin  #25 

2150.  800  --  pin  #26 

2150,  1100  --  pin  #27 

2150,  1400  --  pin  #28 


H.1 .3.  Custom  project  frames 

A  project  is  presumed  to  use  a  custom  frame  if  it  has  not  been  declared  to  use  a  standard  frame  (via 
the  STD-FRAME  parameter).  For  custom  frame  projects,  MOSIS  creates  unique  individual  bonding 
maps  reflecting  the  actual  pad  layout  in  the  CIF  file. 

The  BOND-SAME-AS  parameter  may  be  used  to  specify  the  need  for  bonding  of  one  project  to 
duplicate  that  of  an  earlier  project  (see  Section  D.2). 

MOSIS  requires  adherence  to  two  bonding  rules  not  included  in  "Introduction  to  VLSI  Systems"  by 
Mead  and  Conway.  Failure  to  comply  with  these  rules  may  be  fatal  to  device  performance.  They  are: 

1.  Projects  must  use  pads  (glass  cuts)  not  less  than  90microns  (3.5  mil)  square,  with 
center-to-center  spacing  of  not  less  than  200microns  (8.0  mil).  Note  that  these  are 
absolute  sizes,  independent  of  the  value  of  lambda.  Glass  cuts  must  be  easily  identified 
by  an  operator  using  a  low-power  (low-quality)  microscope.  Cuts  at  random  places  over 
metal  strips  may  not  be  noticed  by  the  bonding  staff. 

2.  Pads  for  bonding  should  be  placed  along  the  edges  of  the  project  (preferably  in  a  uniform 
distribution)  and  not  inside  the  project.  This  simplifies  the  bonding  task  significantly. 

There  should  be  no  more  than  N/4  pads  per  side,  and  no  more  than  a  total  of  N-1  pads, 
where  N  is  the  package  lead  count.  For  MOSIS  standard  packages,  N  is  either  28, 40,  64, 
or  84.  It  is  highly  recommended  that  users  leave  one  pin  of  the  desired  package  free. 

This  will  be  very  helpful  if  it  becomes  necessary  to  use  packages  where  pin-1  is  tied  to 
the  body.  A  project  that  uses  all  available  pins  of  one  size  package  will  ordinarily  be 
packaged  in  the  next  larger  size,  unless  an  ATTENTION  request  is  received  detailing  the 
need  for  a  specific  size. 

Complying  with  these  rules  is  required  for  proper  bonding,  given  compliance  with  other  bonding 
rules. 

Please  refer  to  the  MOSIS  design-rule  documents  for  more  details  regarding  bonding  pads,  especially 
when  2nd-metal  is  used.  The  MOSIS  NMOS  design  rules  are  described  in  detail  in  the  INFORMATION 
document  for  TOPIC:  NMOSDR. 

H.2.  Project  vs.  Die  Size 

A  MOSIS  die  consists  of  a  fixed  starting  frame  plus  a  payload  area  that  is  available  for  user  projects. 
Small  projects  are  often  packed  together  in  a  single  die,  while  large  projects  tend  to  occupy  their  own 
dies.  The  MOSIS  starting  frame  consists  of  a  frame  around  the  die  perimeter  plus  a  horizontal  swath 
across  the  top  of  the  die  to  hold  die  identification  markings.  The  frame,  consisting  of  a  half-scribe 
lane  and  a  metal  guard  ring,  uses  85  microns  per  side,  while  the  marking  swath  across  the  top  is  560 
microns  high.  In  addition,  a  minimum  spacing  of  15  microns  is  enforced  between  any  two  entities, 
wh..:her  guard  ring,  test  strip,  or  user  project(s). 
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Taken  together,  this  overhead  causes  the  user  payload  area  to  be  200  x  300  microns  smaller  than  the 
die;  the  MOSIS  standard  maximum  project  size  of  6900  x  6800  microns  is  based  on  this  overhead  and 
a  die  that  is  7100  microns  square.  Any  project  that  is  larger  than  this  maximum  project  size  requires 
an  oversize  die  and  is  treated  as  an  oversize  project.  Note  that  MOSIS  will,  at  its  convenience,  place  a 
project  on  a  die  either  "as  received"  or  rotated  ninety  degrees  counterclockwise. 

Note:  Following  sections  will  consider  die  size  rather  than  project  size;  the  reader  may  translate  to 
project  size  by  subtracting  the  overhead. 

H.2.1 .  Mask  manufacturing  considerations 

MOSIS  masks  are  produced  using  E-Beam  systems  (manufactured  principally  by  Perkin-Elmer  ETEC 
and  Varian  Associates).  These  systems  read  pattern  files  to  produce  bit  maps  that  are  then  used  to 
drive  the  E-Beam  in  a  raster  scan  operation.  Due  to  bit  map  size  restrictions  that  apply  to  operations 
regularly  invoked  by  MOSIS  (e.g.,  pattern  sizing),  we  are  currently  limited  to  dies  that  are  no  more 
than  8192  microns  wide  (there  is  no  practical  limit  on  die  height).  MOSIS  therefore  treats  8192 
microns  as  its  maximum  die  width  and  turns  ’wide’  projects  on  end. 

H.2.2.  Packaging  considerations 

A  project  which  is  to  be  packaged  and  bonded  must  reside  on  a  die  that  will  fit  into  the  cavity  of  the 
intended  package.  The  28-pin,  40-pin,  64-pin,  and  84-pin  packages  used  by  MOSIS  come  in  a  few 
standard  cavity  sizes,  the  largest  of  which  can  accommodate  a  square  die  of  approximately  the 
following  size: 


Cavitv 

Maximum  Die  Dimension 

28-pin 

7.76  mm 

6.25  to 

7.25  mm 

40-pin 

7 . 75  mm 

6.25  to 

7 . 25  mm 

64-pin 

10.00  mm 

8.50  to 

9 . 50  mm 

84-pin 

11.00  mm 

9.50  to  10.50  mm 

The  die  dimension  limit  allows  for  leeway  between  cavity  and  die  to  facilitate  the  actual 
die-to-package  wire  bonding.  This  leeway  is  not  exact;  the  cited  lower  limit  is  conservative,  while  the 
upper  is  somewhat  high.  Note  that  the  MOSIS  standard  die  size,  7.1  mm,  is  near  the  upper  limit  for  the 
40  pin  package. 

Users  with  special  needs  should  secure  their  own  packages  for  MOSIS’s  use  in  bonding  their 
projects.  Each  such  case  must  be  negotiated  individually  to  determine  whether  the  MOSIS  packager 
can  handle  such  parts. 
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H.2.3.  Wafer  layout  and  die  size  selection 

Fabricated  wafers  are  diced  into  individual  dies  by  sawing  the  wafer  through  the  scribe  lanes.  Thus 
the  die  layout  on  the  wafer  must  result  in  a  reasonable  grid  that  is  amenable  to  sawing.  A  general 
consequence  is  that  each  unique  die  size  on  a  wafer  must  be  allocated  a  substantial  portion  of  the 
available  real  estate.  To  the  extent  that  a  multiplicity  of  die  sizes  complicates  wafer  sawing,  it  also 
adds  both  risk  and  delay  to  the  packaging  process. 

The  selection  of  a  set  of  die  sizes  for  any  particular  MOSIS  fabrication  run  is,  and  will  remain,  a  human 
judgment  operation  that  takes  into  account  the  set  of  projects  actually  submitted,  the  relative  area 
requirements,  the  p  jtential  wafer  layout,  and  the  actual  wafer  size  used  by  the  selected  fabricator. 

H.2.4.  Project  vs.  die  size  summary 

1.  MOSIS  cannot  fabricate  any  dies  wider  than  8192  microns.  The  smaller  dimension  of  a 
project  must  therefore  be  less  than  7980  microns. 

2.  MOSIS  will  NOT  fabricate  any  (oversize)  project  that  cannot  fit  into  an  appropriate 
package  UNLESS  the  user  either: 

•  declares  explicitly  that  he  wants  unpackaged  parts,  or 

•  with  prior  approval,  provides  to  MOSIS  the  necessary  packages  for  his  project. 

Die  size  and  wafer  layout  considerations  may  cause  some  or  all  oversize  projects  to  be  omitted  from  a 
particular  run.  Therefore,  while  MOSIS  will  attempt  to  give  timely  service  to  all  submitted  projects, 
oversize  projects  cannot  be  guaranteed  fabrication  on  the  first,  or  any  particular,  fabrication  run 
subsequent  to  their  submission. 

H.3.  Production  Parts 

MOSIS  maintains  a  list  of  projects  needing  production  quantities  for  prototype  evaluation  and  similar 
purposes.  Each  of  these  projects  will  be  fabricated  on  each  subsequent  appropriate  run  until  the 
needed  production  quantity  for  the  project  has  been  fabricated  and  delivered,  at  which  time  the 
project  will  be  taken  off  the  list. 

Priority  in  the  production  of  parts  from  this  list  will  be  given  to  those  projects  which  will  be 
wafer-probe  screened  (i.e.,  not  requiring  packaging  for  testing). 

In  order  to  have  a  project  included  on  the  production-quantity  list,  the  user  responsible  for  the  project 
must  send  justification  for  inclusion  to  the  appropriate  DARPA  or  NSF  sponsor;  additionally,  the 
project  must  have  already  been  tested  to  eliminate  design  errors  and  to  prove  feasibility  for 
production  use. 


The  justification  must  include  the  MOSIS  project  ID,  the  latest  Fab-ID,  the  quantity  of  parts  needed, 
and  a  copy  of  the  report  which  the  user  has  already  sent  to  MOSIS  concerning  the  small-quantity  dies 
which  the  user  has  tested. 

Anyone  receiving  parts  from  the  production-quantity  list  will  be  expected  to  provide  MOSIS  with 
reports  following  the  testing  of  parts  from  each  run.  A  final  report  concerning  the  performance  of  the 
parts  in  the  intended  production  environment  will  be  expected  within  a  reasonably  short  interval 
following  the  final  delivery  of  parts. 

(I)  Netmail  Procedures 

1.1 .  Internet  Addresses 

The  NET-ADDRESS  parameter  for  a  MOSIS  project  request  (NEW-PROJECT,  SUBMIT,  FABRICATE, 
etc.),  should  follow  the  syntax  for  ARPA  Internet  messages  as  specified  in  "Standard  for  the  Format  of 
ARPA  Internet  Text  Messages",  by  David  H.  Crocker,  RFC  822,  NIC  41952,  available  from  the  Network 
Information  Center.  The  following  limitations  apply: 

1.  The  address  parameter  must  fit  on  one  line  of  less  than  200  characters;  address  "folding” 
is  not  supported. 

2.  The  special  characters  <CR>,  <LF>,  and  <NUL>  may  not  be  part  of  the  address(es),  even  if 
part  of  a  quoted  string  or  quoted  pair. 

For  users  who  are  NOT  directly  connected  to  the  Internet,  but  are  connected  to  a  local  net  accessible 
through  a  host  on  the  Internet,  the  net-address  given  must  be  to  a  mailbox  on  the  Internet  host,  rather 
than  on  the  host  within  the  local  net.  MOSIS  maintains  no  table  associating  the  local-net  name  for  a 
host  and  the  particular  Internet  host  handling  mail  for  that  site.  The  correct  form  of  Internet  address 
is  idiosyncratic  to  the  site. 

1.2.  Telemail  Addresses 

The  way  to  send  messages  to  MOSIS  from  TELEMAIL  is  by  sending  a  TELEMAIL  message  to 
MOSIS/USCISI.  Any  NET-ADDRESS  parameter  (as  is  needed  in  any  project-related  request)  must  be 
of  the  following  form: 

XXX/YYY  <MOSIS.TELEMAIL> 

where  "XXX/YYY"  is  the  TELEMAIL  address  to  receive  replies  from  MOSIS.  For  example,  the 
following  would  be  a  valid  NET-ADDRESS  parameter  line: 

NET-ADDRESS:  RICHARDSON/USCISI  <MOSIS.TELEMAIL> 


1.3.  ARPA  Internet  Mail  Size 

With  the  adoption  of  new  software  for  the  handling  of  ARPA  Internet  mail,  MOSIS  presently  must  deal 
with  the  following  limitation  un  the  size  of  ARPA  Internet  mail,  both  incoming  and  outgoing:  no  single 
item  of  Internet  mail  having  more  than  about  890,000  characters  can  be  handled,  to  or  from  MOSIS. 

This  limitation  may  eventually  be  removed,  but  for  the  time  being,  any  user  having  a  project  CIF  of 
more  than  about  890,000  characters  should  submit  that  project  in  CIF-fragments  of  less  than  890,000 
characters  each  (including  message  headers). 

Please  note  that  this  limit  does  NOT  apply  to  the  transfer  of  CIF  files  via  the  specification  of  a 
CIF-FTP-PATH. 
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